Smith
In plain words: Code assimilation agent
The planned agent (Smith) that turns an admitted outside pattern, protocol, defect or need into candidate code, tests and docs inside an isolated lab, with full source, license and authorship records.
- 1Source must be admitted with known identity, provenance and license before it can support a promotion request.
- 2The author agent writes only to permitted lab paths; no access to the live checkout, secrets, migrations or publishing.
- 3Tests, evaluation (Drift), approval (HitL), packaging and activation are separate owners; no self-certified loop.
Designed No candidate-author agent or end-to-end assimilation path is delivered.
Words on this page, decoded click one for its card
Purpose is the hammer.
Pattern is the anvil.
Consent is the seal.
What is worthy becomes organ.
Suppose foreign craft exposes a useful pattern or a defect the local body should learn from. Smith, the Assimilation Extension DomainPlug-in Area, defines a candidate-author Agent for that work. Given an admitted pattern, protocol, defect, or need, the Agent can prepare code, schemas, migrations, tests, documentation, and packaging inputs in a bounded Lab coordinate. Attribution makes the result examinable. The candidate has not yet become an organ of the running body.
Maturity: Designed. No candidate-author Agent or end-to-end Assimilation path is delivered. ADR 35 owns the architecture and full protocol; State of Work owns delivery.
The hammer has no crown
First establish what material the author may use. Scout can acquire exact source, but its custody owner must validate and admit the bytes before Smith receives them. Another source/custody route can provide the same settled handoff.
The Assimilation Dossier then carries the source identity and revision, acquisition path, license and notice duties, local base, transformations, Smith/model/tool/human authorship, unresolved gaps, and maintenance lineage. Without established identity, provenance, or license, material may inform study but cannot support a promotion request.
The candidate-author Agent may read admitted source and relevant Core code, then write only to permitted Lab paths. It can submit typed requests, but receives no ambient access to the active checkout, dependency locks, secrets, migrations, package publication, or host lifecycle.
The declared harness records deterministic facts such as lint, type, build, or test results; Drift owns calibrated quality and comparative claims. The required HitL or eligible policy decision supplies promotion consent. Forge constructs package or image artifacts from reviewed inputs, while CodexSettings Folder, migration, and lifecycle owners perform their own effects. A passing check supports only its declared predicate; ADR 35 keeps the exhaustive authority matrix.
Protocol stages, not a second coordinator
exact intent and admitted source
→ Dossier and isolated Lab candidate
→ deterministic receipts and Drift findings
→ promotion request
→ required HitL/policy and target-owner decisions
→ owned packaging and live effects
→ reassembly and observation
The path is compact, but its records are not disposable. Source revision, license, transformations, candidate parentage, tools and providers, human edits, checks, failures, and the final decision remain attributable.
The candidate-author role needs an application to give it executable work. An exact application PatternWorkflow must select a registered AgentSpec satisfying that role; SpellweaverWorkflow Engine can then admit and perform its pinned ScrollWorkflow Version. Verification, consent, packaging, migration, and activation remain later effects of their respective owners, each receiving a settled typed request.
Smith supplies neither aan CompositionApp nor aan SuiteApp Bundle nor another coordinator. No exact application PatternWorkflow or SuiteApp Bundle currently defines end-to-end Assimilation, so this reference protocol remains non-executable.
Each arrow above is a governance dependency between separately owned, already-settled records. It is not one hidden RunJob Record that waits for, retries, cancels, recovers, or jointly settles every owner. A future application PatternWorkflow may own one bounded candidate-author job; a separately named SuiteApp Bundle is required if one reusable promise must actively coordinate multiple CompositionApp InvocationsJob Requests.
Repair and evolution
The Creation workflow gives candidate authors a repeatable method from intent and evidence through construction, verification and documented disposition. The wider Ouroboros map returns consequences to evaluation and separately admitted correction, including teaching, training and later body generations.
A candidate-author Agent may prepare a pinned update or propose a bounded correction in Shadow. Each revision retains parentage and repeats every invalidated check; the author cannot certify its repair or widen its budget.
If a required migration rehearsal still fails when that budget expires, the attempt records explicit non-completion, preserves the Dossier, candidate, and failure receipts, and leaves the running body unchanged. Any later attempt receives a new candidate identity and re-enters the affected gates. No autonomous loop may join authorship, judgment, consent, packaging, migration, or activation into a self-certified result.