27 lines
4.3 KiB
Markdown
27 lines
4.3 KiB
Markdown
|
# Local agent and modularity review
|
||
|
|
|
||
|
|
13 October 2026. This record covers the local-agent and modularity additions after the architecture v0.2 review. It does not establish runtime acceptance.
|
||
|
|
|
||
|
|
## Requirement and reference findings
|
||
|
|
|
||
|
|
The owner requested a custom local agent with skills and pipelines, similar to their RESEARCH agents, and required replaceable modules throughout development. Inspection of Winnow in SCAR and Praxis in CV confirmed the relevant pattern: a workspace role, shared protocols, reusable skills and coordinating procedures executed by an existing host. SCAR's `.agents` points to `.opencode`; CV owns `.agents` directly. Their runtime workflows were not retested, and no reference-workspace instructions were activated for this task.
|
||
|
|
|
||
|
|
The [local-agent decision](../architecture/LOCAL_AGENT.md) adopts this form. The [source pack](../../agents/gewu/README.md) contains a profile, readiness/version manifest, evidence/scope/contribution protocols, four skills and four pipeline procedures. It introduces no standalone reasoning engine. Service compatibility and native host acceptance remain unverified. Files are supplied in the repository; no user-global configuration or installed research workspace was changed.
|
||
|
|
|
||
|
|
## Design changes
|
||
|
|
|
||
|
|
The [modularity protocol](../development/MODULARITY_PROTOCOL.md) makes public contracts, owned state, dependency direction, versioning, migration and replacement evidence explicit. It covers backend adapters, agent instructions, connector and frontend. A modular monolith is the service default; process separation is a deployment decision. Replacement must preserve behavioral and security invariants or declare an explicit contract migration.
|
||
|
|
|
||
|
|
The GOAL, PRD, architecture, development and security documents now distinguish the custom local profile from reasoning inside the knowledge service. The profile supplies ingest, query, curate and synthesize procedures; existing P1 synthesis and advanced-curation service priorities remain unchanged. Checkpoints preserve versions and outputs, while actual service receipts remain authoritative for acceptance. Markdown instructions do not establish durable execution, native skill discovery or safe retry behavior by themselves.
|
||
|
|
|
||
|
|
## Verification
|
||
|
|
|
||
|
|
All four skills pass the skill-creator structural validator. That check covers frontmatter and basic skill structure; it does not test semantic quality, tool connectivity or host behavior. A separate manifest check passed for all 12 referenced paths, unique skill IDs, matching skill names and pipeline versions, and explicit unverified compatibility status.
|
||
|
|
|
||
|
|
Across 30 Markdown files, local links and heading anchors resolve; fence and trailing-whitespace checks found no issues. The prose scan checked 76 patterns across the 16 new pack/design/review files and found no matches. `git diff --check` passed. These are static checks; they establish neither execution nor replacement behavior.
|
||
|
|
|
||
|
|
The bounded independent review found no blocker and one major gap: the pack's own profile and protocols lacked versioned replacement contracts. The repair adds descriptors for every instruction module and the checkpoint guide, explicit dependencies, checkpoint compatibility, per-file hashes and a snapshot digest. Contribution instructions require those IDs and digests in run records. Service capability binding remains explicitly pending. The descriptor/hash checks establish internal consistency; native resumption and upgrade compatibility still need execution tests.
|
||
|
|
|
||
|
|
The reviewer confirmed that finding closed at design level with no residual concrete defect. Final checks cover 13 module descriptors and hashes, their internal dependencies, the snapshot digest, 129 local links and five anchors. Markdown hashes normalize UTF-8/BOM and line endings as specified in the pack guide so checkout conversion does not change instruction identity. Hashes establish content identity, not trust or execution safety.
|
||
|
|
|
||
|
|
Runtime acceptance remains pending: install into a disposable workspace after the service contracts exist, verify discovery and read-only retrieval, then complete ingestion, invalid-evidence rejection, uncertain-result recovery and resumption with pinned versions. Full-v1 host claims require the declared client matrix. Module substitution, migration and rollback tests must accompany implementation.
|