Project Wiki synthesis
Type: agentic-system-analyses/types/agentic-system-synthesis.md
Bounded synthesis
A project-memory skill, not an enclosing runtime
Project Wiki supplies a portable coding-agent skill, local Python helpers and templates for a repository-local .project-wiki/. Its intended work is to preserve requirements, decisions, implementation knowledge and history for later tasks. This analysis covers the complete shipped memory loop at Git commit 3af1e28d0a3ed3daeb9f923102cd5cefb51b0f41, with an applicability cutoff of 2026-11-08. The sole source, SRC-1, provides inspected helper implementation and workflow/design text. No populated consuming-project wiki, host execution trace or causal experiment is supplied. Tests and CI declarations are not successful-run evidence (boundary and coverage, Source register, RT-CLM-project-memory).
The foreground host agent owns interpretation, workflow choice, semantic judgments, canonical edits and continuation after helper returns. Project Wiki supplies no enclosing model runtime or independent scheduler. Its explicit modes include initialization, scanning, update, synchronization, maintenance, configuration and help. Helpers perform byte-level and structural work; natural-language procedures govern semantic work. Generated repository instruction blocks request consultation and updates on future tasks, conditional on the host loading and obeying them. Host permissions, model versions, provider behavior and context-window policy are not established (RT-CMP-host-agent, RT-OBJ-skill, RT-BAP-project-protocol).
Establishing retained knowledge
Initialization first publishes a structurally validated scaffold. The helper explicitly does not claim completed project understanding: the host must capture project-specific content and install the instruction blocks. Semantic records distinguish confirmed product intent from observed implementation and inferred or unresolved claims. Requirements require explicit intent; code behavior belongs in technical documentation unless an intent source confirms it. Durable exploratory analysis remains distinct from canonical records (RT-RTE-initialize-wiki, MEM-OBJ-canonical-records, EPI-OBJ-requirements, EPI-OBJ-technical, EPI-OBJ-analysis).
The representative workflow is an explicit update with a processable inbox document. It was selected because the shipped instructions connect request, extraction, review, admission and delivery rather than merely exposing unrelated tools. The foreground agent calls inbox preflight, consumes its process/skip/review decision and passes the reported source hash into extraction. Helpers snapshot and extract supported text, publish chunk files and provenance, and initialize mutable review state. Source archival can precede semantic integration: a processed raw source is not yet an integrated intake (workflow account, RT-RTE-source-intake, MEM-OBJ-source-registry).
The same agent then requests source sections or the full document, compares content with existing project records, and records a final classification or skip reason for every chunk. The ledger permits review resumption without retaining the original conversation window. It does not prove that the source was read accurately. Extracted text remains provenance until semantic admission; terminal intake is normally excluded from ordinary coding consultation, but remains available for provenance or conflict investigation (MEM-OBJ-intake-provenance, MEM-OBJ-review-progress, EPI-RTE-content-compare).
Explicit update authorizes conservative source-backed integration, not human approval of each assertion. The host normally admits clear information directly and preserves nonblocking uncertainty in status, confidence, questions or alerts. A human decision is required for enumerated blocking authority, scope, incompatible-baseline or binding choices, unauthorized changes to confirmed intent, or requested review-only work. Resolving that decision resumes the same integration without a second approval for the same choice. Admission, file retention and post-admission linking are separate functions. Atomic requirement-to-chunk edges live in a YAML sidecar rather than readable requirement bodies (EPI-RTE-content-admit, EPI-RTE-canonical-retain, EPI-RTE-canonical-link, MEM-OBJ-requirement-evidence).
What completion checks actually establish
Ledger audit checks state and optionally exact ledger bytes. It can return exit zero while reporting incomplete review; the host must consume the reported status. The audit neither commits final intake status nor locks subsequent edits. Structural validation checks coverage, registered targets and reciprocal requirement-evidence edges, not source entailment. Delivery requires canonical integration, traceability, audit evidence, lifecycle updates and a final report or exact blocker—not extraction success alone (EPI-RTE-ledger-check, EPI-RTE-structure-check, workflow finalization).
The scope of other controls is similarly local. Inbox hash binding is required by its procedure; direct explicit document extraction can omit the expected hash. Pasted notes and durable chat answers bypass document chunk review. Source exclusions filter named helper paths, not raw host filesystem access; the supported outside-repository local-file intake shape is not covered by the conditional in-repository ignore checks. Existing extracted history remains available. These are neither universal admission controls nor a sandbox (RT-RTE-source-intake, RT-RTE-note-update, runtime forcing cases).
Helper failure cleanup is local, not rollback of the whole semantic write set. Bad extraction before integration must be rejected or superseded and regenerated; after integration the host must also correct affected canonical records and append audit history. Scaffold exclusive publication is not generalized to intake's existence-check-and-rename publication (RT-RTE-initialize-wiki, RT-RTE-source-intake, workflow recovery).
Later use and correction
On an ordinary coding task, the prescribed preflight reads the root index, chooses a relevant section index, then loads only needed pages. Registry and traceability supply fallback routes. This is host judgment over task relevance, not vector retrieval or a fixed numerical ranking. Task-triggered selection is an afforded automatic supply path; subsequent file and review-view requests are requested retrieval. Section/chunk views deliver selected full text into the same foreground context. All chunks are loaded from disk before review output selection; section or full-document output has no token bound. Progressive disclosure limits acquisition, not host-window eviction, compaction or isolated worker frames (RT-RTE-coding-cycle, MEM-OBJ-wiki-routing, memory intake annotation).
After a coherent coding task, the agent assesses durable wiki impact and updates affected records, or returns without metadata churn. False or invalid automatic-write configuration suspends that assessment and automatic writes, but not preflight, requested code work or explicit update/sync/maintain. The setting is a host policy, not a lock consumed by every writer. Explicit synchronization checks current sources against retained claims using a reliable baseline where available. Maintenance runs structural validation before semantic lint; low-risk repairs are direct, while high-impact canonical meaning changes require confirmation. History and withdrawn claims are preserved (MEM-OBJ-project-controls, RT-RTE-explicit-reconcile, EPI-RTE-semantic-lint, EPI-RTE-claim-withdraw).
The strongest supported learning-related contribution is an afforded text-memory pathway: conversational answers pass through a lasting-value judgment into durable records or analysis, then can become later task context. Conversational experience shapes the update; the resulting text supplies knowledge to the later reader. This does not require parameter training or novel propositions, but it establishes neither exercised use nor improved capacity for future action. Other task/history-derived learning routes retain unresolved qualification and input origin (memory note-update annotation, RT-RTE-note-update, profile verification).
Semantic maintenance provides a prescribed route for criticism and changed reliance on project claims. The accepted records do not establish an iterative theory-building episode or improvement of the skill's own method. They do not supply separate positive assessments of theory-builder conditions 1–4, reflection or autonomous theory building. Exercised self-improvement is likewise unestablished: a retained update and intended later reader do not show subsequent operation causally depending on evidence-responsive changes to the system's own organization. These are independent limits, not a blanket absence inferred from missing runs (epistemic conclusion, report verification).
For document-backed project memory, the discriminating result is inspectable separation of source provenance, semantic admission, canonical use and recovery history. For unattended maintenance or demonstrated improvement in coding, the same evidence is insufficient: continuation and semantic evaluation depend on an unspecified host. A populated intake with source-to-record decisions, resumed review and later task traces would establish exercised routes; independent outcome comparisons would be needed for benefit or component attribution. Atomic finalization, an enforced context budget or a centrally mediated write gate would change the corresponding control assessment, but none follows from the present protocols.
Limitations
Neither supplied verification declares additional limits or blockers, and reconciliation reports no unresolved conflict. The following evidence and scope limits remain consequential.
| Limitation | Affected SRC IDs and record citations | Inspected boundary | Conclusion prevented | Evidence that would resolve it |
|---|---|---|---|---|
| Host activation and model behavior are unspecified | SRC-1; RT-CMP-host-agent, RT-BAP-project-protocol, RT-RTE-coding-cycle | Shipped procedures, templates and helpers; no deployed host implementation or trace | Reliable automatic invocation, instruction compliance, exact model identity/mutability or exercised cross-session recall | Pinned host configuration and traces showing instruction loading, selection and subsequent action |
| No populated canonical acceptance or review-resumption instance | SRC-1; MEM-OBJ-review-progress, MEM-OBJ-canonical-records, EPI-RTE-content-admit | Artifact contracts and semantic procedures, not a consuming wiki | Actual source-faithful admission, rationale completeness or successful interrupted-review recovery | Source-linked candidate, decision, ledger and canonical artifacts plus a resumption trace |
| Extraction does not resolve all original content or upstream warrant | SRC-1; MEM-OBJ-intake-provenance, EPI-RTE-extract-source, MEM-OBJ-source-registry | Inspected extraction code and declared format scope; dependency internals and binary/nontext content unresolved | Format-wide semantic fidelity, complete original-payload classification or source truth | Representative originals compared with extracted content, dependency evidence and source-authority/provenance records |
| Structural checks and checkpoint digest do not establish semantics or atomic finalization | SRC-1; EPI-RTE-ledger-check, EPI-RTE-structure-check | Ledger/state/edge checks and separate host status mutation | Entailment, proof of reading, or a lock over the whole integration | Evidence-consuming semantic decisions; a transaction or equivalent enforced finalization mechanism for atomicity |
| Selective loading supplies no enforced context budget | SRC-1; MEM-OBJ-wiki-routing, RT-RTE-source-intake | Index routing and review-output selection | Bounded token use, eviction, compaction or context isolation | Host context-management implementation and invocation traces with explicit budget accounting |
| Direct-edit control and model-authored novelty remain unresolved | SRC-1; MEM-OBJ-project-controls, EPI-OBJ-analysis, EPI-RTE-content-compare | Prescribed admissions and generic file-edit alternatives; no concrete synthesis candidate | Complete write-agency classification or a produced accepted ampliative claim | Per-content edit authorization/provenance and input-output claims with their acceptance evidence |
| Trace-fed memory does not establish benefit or complete learning-route coverage | SRC-1; RT-RTE-note-update, RT-RTE-coding-cycle, MEM-OBJ-audit-history | Afforded answer-to-record-to-later-context chain; other input mixtures unresolved | Improved future capacity, exhaustive trace-origin classification, or exercised self-improvement | Update and later-use traces, identified original activity inputs, objective-bearing evidence and comparisons isolating the claimed effects |
| No evidenced iterative theory-building or reflective/autonomous episode | SRC-1; EPI-RTE-semantic-lint, EPI-RTE-claim-withdraw, RT-RTE-explicit-reconcile | Project-claim correction procedures, not a separately assessed self-method revision loop | Positive theory-builder, reflection or autonomous-theory-builder attribution | Localized theory, demonstrated consumption, content-directed criticism and retained next-round effects; property-specific self-representation and role evidence |