thoth-agents 0.10.0 → 0.11.0

package/plugin/skills/thoth-sdd/references/phases/verify.md

@@ -4,7 +4,7 @@ Every change requires final verification against accepted outcomes and actual ex
 
 For Oracle final verification of a small change without a record, require a valid delivery verdict with `mode:"no-record"`, null `record` and `recordSha256`, and `recordDigest:"none"`. Oracle omits both `reviewedRecord` and `reviewedRecordSha256`. Only in the CLI fallback, root passes `--no-record`. Do not combine `--no-record` with `--record-sha256` or plan-review. Otherwise final verification still requires both binding fields.
 
-Before requesting final Oracle for substantial work, run `node "<skill-dir>/scripts/validate.mjs" --change .thoth/changes/<id> --through verify --json`. This gate requires ready coverage, complete tasks, authorization disposition/provenance, and reviewed source digests/baselines; final-review fields, AC evidence rows, and Archive may remain placeholders. For each capability named by a durable delta, add exactly one `Source` entry for `.thoth/specs/<capability>/spec.md`: its reviewed SHA-256 when it exists, or `absent` only when no canonical file exists.
+Before requesting final Oracle for substantial work, root runs `node "<skill-dir>/scripts/validate.mjs" --change .thoth/changes/<id> --through verify --json`. This gate requires ready coverage, complete tasks, authorization disposition/provenance, and reviewed source digests/baselines; final-review fields, AC evidence rows, and Archive may remain placeholders. For each capability named by a durable delta, root adds exactly one `Source` entry for `.thoth/specs/<capability>/spec.md`: its reviewed SHA-256 when it exists, or `absent` only when no canonical file exists.
 
 Assign Oracle a `final-verification` review of the substantial record. Oracle returns exactly one fenced `thoth-result` JSON envelope as the entire final message, following the Oracle gate contract with `role: "oracle"`, `review.kind: "final-verification"`, and `review.verdict: "PASS" | "FAIL" | "BLOCKED"`. Its review includes `reviewedRecord` naming the reviewed record path and `reviewedRecordSha256` containing the 64 lowercase hex SHA-256 of exact UTF-8 record bytes preceding the case-sensitive `## Authorization` heading. PASS requires `status: "complete"` and no blocking risks. FAIL reports findings; BLOCKED is an actual inability to complete review, never a substitute for a malformed result or exhausted format repair.
 
@@ -12,10 +12,17 @@ Record equality, `mode` and `recordDigest` checks apply only to final verificati
 
 Root uses the harness-delivered `thoth-gate-verdict` under thoth-sdd **Specialist result validation**: exactly one outside the envelope fence, `valid:true`, assigned `kind:"final-verification"`, `verdict:"PASS"`, assigned `record`, `mode:"record"`, and `recordDigest:"match"`. Never re-emit the envelope to validate it. If a valid verdict reports `recordDigest:"unavailable"`, independently hash exact UTF-8 record bytes before `## Authorization` and compare with `recordSha256`; mismatch or unavailable calculation means no approval, with no validator rerun. Use the explicit compact CLI fallback only when no verdict was delivered: unchanged result, `--review-kind final-verification --record-sha256 <hex>` with the independently calculated expected prefix digest. Claude Code verdicts arrive with Subagent hand-back reports (foreground or background; `agent` is the agent id, match it to the Agent result's `agentId`) and completed foreground `Agent` results whose content carries the report. Other deliveries (e.g. background runs without hand-back) carry none; use the explicit compact CLI fallback.
 
-Root records `**Reviewer**: oracle`, `**Independent from implementer**: Yes`, `**Verdict**: PASS`, and `**Reviewed record SHA-256**` only from a validated PASS whose digest matches the current record, after judging content and confirming reviewer independence and provenance. Copy the verdict and `recordSha256` into the record (accepted CLI summary/digest in fallback); use `recordSha256` for the SHA field. Invalid results, FAIL, BLOCKED, and diagnosis/advice reviews do not authorize closeout or archive; route findings to convergence and report contract failures truthfully.
+Root records `**Reviewer**: oracle`, `**Independent from implementer**: Yes`, `**Verdict**: PASS`, and `**Reviewed record SHA-256**` only from a validated PASS whose digest matches the current record, after judging content and confirming reviewer independence and provenance. Root copies the verdict and `recordSha256` into the record (accepted CLI summary/digest in fallback); use `recordSha256` for the SHA field. Invalid results, FAIL, BLOCKED, and diagnosis/advice reviews do not authorize closeout or archive; route findings to convergence and report contract failures truthfully.
 
 Substantial records must not contain other `thoth-result` fences or `**Oracle envelope**:` marker lines anywhere in the file; write examples inline instead.
 
 Order: `verify` → fresh final Oracle → root validates and pastes → `closeout` → archive. After accepting a validated PASS, root pastes the Oracle's unchanged final-verification envelope under `**Oracle envelope**:` in the record's Verification section (post-PASS bookkeeping in Verification; no new review). Plan-review envelopes are not embedded. Closeout fails without exactly one valid PASS envelope matching the record path and prefix digest, consistent with `**Verdict**` and `**Reviewed record SHA-256**`. Preserve the envelope unchanged when archiving; archived validation accepts its original active record path. Historical archived records are not retrofitted or re-validated by this rule.
 
-After accepted review, record each outcome's concrete PASS evidence, actual checks, source SHA-256 digests, and the matched record-prefix hash. After PASS, edits confined to Authorization, Verification, or Closeout need no new review; any edit before `## Authorization` requires fresh independent review and a new digest. This allowance never waives structural checks, truthful provenance, stale-source rejection, or review of changed implementation. Recheck baselines after review; missing or stale digests/absence, missing evidence, or blockers prevent closeout and archive. Never create a verification report or evidence directory; route actionable findings to convergence.
+After accepted review, root records each outcome's concrete PASS evidence, actual checks, source SHA-256 digests, and the matched record-prefix hash. After PASS, edits confined to Authorization, Verification, or Closeout need no new review; any edit before `## Authorization` requires fresh independent review and a new digest. This allowance never waives structural checks, truthful provenance, stale-source rejection, or review of changed implementation. Recheck baselines after review; missing or stale digests/absence, missing evidence, or blockers prevent closeout and archive. Never create a verification report or evidence directory; route actionable findings to convergence.
+
+
+Plan review OKAY/REJECT judges the record; root repairs REJECT. Final verification PASS/FAIL judges the implementation.
+
+Root records remaining acceptance-linked work in the substantial record when one exists, otherwise in the brief in-session small plan; the owning Worker or Designer repairs each affected surface; root coordinates and does not repair implementation unless the user explicitly instructs direct work; even then, never self-approve and report unavailable independent review.
+
+Repeat independent verification as the change's verification level requires; substantial or materially risky work uses a fresh Oracle. Material changes in intent, scope or risk reopen understanding and planning before further implementation.

package/plugin/skills/thoth-sdd/templates/change.md

@@ -45,7 +45,8 @@ remaining fields below it. Repeat an AC number when separate units contribute
 to that acceptance outcome. The row text names one reviewable result; do not
 combine separately acceptable outcomes into a phase-sized task. Fill the
 indented fields with concrete information. For a read-only unit, write `none`
-for owned writes.
+for owned writes. Owner names the role executing the task unit; root always
+writes the record.
 
 - [ ] AC-1: TBD
   - Outcome: one result that root can accept independently

package/skills/plan-reviewer/SKILL.md

@@ -50,14 +50,14 @@ reports (foreground or background; `agent` is the agent id, match it to the Agen
 result's `agentId`) and completed foreground `Agent` results whose content carries
 the report. Other deliveries (e.g. background runs without hand-back) carry none;
 use the explicit compact CLI fallback.
-Copy the verdict and `recordSha256` into the record (accepted summary/digest
+Root copies the verdict and `recordSha256` into the record (accepted summary/digest
 in fallback). Keep the shared one-request format-only repair budget. Root records
 plan-review `OKAY` only after these checks and judging content and provenance;
 a malformed or missing envelope is not approval.
-Root repairs same-intent blockers in the same record, revalidates affected gates,
-and uses a fresh Oracle for each round. A human-owned material blocker stops the
-round. Root records both review disposition and selection provenance without
-inventing approval. Accepted provenance is `EXPLICIT_REVIEW`, `EXPLICIT_SKIP`, or
+On selected plan-review `REJECT`, root repairs the same record, reruns affected
+gates and sends it to a fresh Oracle until `OKAY` or a human-owned material
+blocker stops the round. Root records both review disposition and selection
+provenance without inventing approval. Accepted provenance is `EXPLICIT_REVIEW`, `EXPLICIT_SKIP`, or
 `DEFAULT_REVIEW_AFTER_3`; `SKIPPED` requires explicit skip, while `OKAY` requires
 explicit review or the third-return review default. After validated `OKAY`, root preserves
 the separate Implement (Recommended) / Stop choice and separately offers it,

package/skills/thoth-sdd/SKILL.md

@@ -33,9 +33,9 @@ resolve material product, architecture, security, or destructive choices.
 ## Proportional classification
 
 - **Small** means local impact, clear intent, and low risk. Local work may touch
-  several files within one area; file count alone never increases scope. Use
-  test-first implementation and focused verification; create no persistent
-  change record.
+  several files within one area; file count alone never increases scope.
+  Before delegating or implementing, root states a brief in-session plan (scope, owner, focused verification). Use test-first implementation and
+  focused verification; create no persistent change record.
 - **Substantial** means coordinated impact across multiple areas, cross-cutting
   contract changes, material uncertainty, or elevated failure/contract risk. A
   small patch can still be substantial when its risk demands planning. Persist
@@ -48,6 +48,13 @@ never build a scheduler, state mirror, or process tooling.
 
 ## Ownership and decisions
 
+Root is the sole record author at every stage: it creates, edits, validates and
+corrects the record. During planning, specialists supply context within their
+full role scope; root never assigns them to create, modify or correct SDD files.
+Record authorship is coordination, not a direct-work allowance for discovery or
+implementation. Implementation writers start only after authorization and never
+write `.thoth/changes/`.
+
 Root owns user intent, scope, material decisions, classification, and final
 acceptance. Root also owns completing understanding, while the specific discovery
 ownership policy determines who gathers evidence; that policy takes precedence
@@ -74,7 +81,10 @@ At substantial `ready`, first show the user a concise plan summary (goal,
 acceptance, key decisions, units, risks, record path), then always offer
 `Review plan with Oracle (Recommended)` or `Proceed without review`, even when implementation was already authorized.
 Silence is never an explicit review skip; run a fresh read-only review only when
-selected. After a validated plan-review `OKAY`, separately offer `Implement (Recommended)` /
+selected. On selected plan-review `REJECT`, root repairs the same record, reruns
+affected gates and sends it to a fresh Oracle until `OKAY` or a human-owned
+material blocker stops the round. After a validated plan-review `OKAY`, separately
+offer `Implement (Recommended)` /
 `Stop`; prior explicit authorization remains valid, while an explicit later
 `Stop` supersedes it. Record the plan-review selection as
 `EXPLICIT_REVIEW`, `EXPLICIT_SKIP`, or `DEFAULT_REVIEW_AFTER_3`; `SKIPPED`
@@ -86,6 +96,14 @@ independent Oracle. An implementation writer never approves its own work. If the
 user forbids delegation, perform authorized work directly but report unavailable
 independent review; never claim independent PASS or archive.
 
+
+
+Plan review OKAY/REJECT judges the record; root repairs REJECT. Final verification PASS/FAIL judges the implementation.
+
+Root records remaining acceptance-linked work in the substantial record when one exists, otherwise in the brief in-session small plan; the owning Worker or Designer repairs each affected surface; root coordinates and does not repair implementation unless the user explicitly instructs direct work; even then, never self-approve and report unavailable independent review.
+
+Repeat independent verification as the change's verification level requires; substantial or materially risky work uses a fresh Oracle. Material changes in intent, scope or risk reopen understanding and planning before further implementation.
+
 ## Bounded execution
 
 Root uses the harness progress tool (Pi `todo`, Claude `TodoWrite`, OpenCode
@@ -121,7 +139,7 @@ and preserve substantive handoffs across late notifications. Load the
 
 ## The sole substantial-change record
 
-After substantial classification, create only
+After substantial classification, root creates only
 `.thoth/changes/<id>/<id>.md` from
 `<skill-dir>/templates/change.md`. Use a safe lowercase kebab-case ID; reject
 Windows-reserved names and unsafe path components. The record covers grounded
@@ -181,7 +199,7 @@ Require `valid:true` and `kind` matches the assignment. Plan review requires
 
 Record equality, `mode` and `recordDigest` checks apply only to final verification.
 See the [verify phase](references/phases/verify.md).
-Copy the verdict and `recordSha256` into the record when there is one; final
+Root copies the verdict and `recordSha256` into the record when there is one; final
 verification uses that digest for `**Reviewed record SHA-256**`. Still judge
 scope, evidence, checks, freshness, provenance, independence, and content.
 Validation is not authorization.
@@ -216,7 +234,7 @@ to the assigned `plan-review` or `final-verification`. For record-bound final
 verification, independently calculate the expected record-prefix SHA-256 and
 pass `--record-sha256 <hex>`. Apply the same kind-specific approval checks above;
 the explicit expected digest supplies agreement if the CLI cannot read the
-record itself. Copy the accepted summary and digest into
+record itself. Root copies the accepted summary and digest into
 the record. For Oracle final verification of a small change without a record,
 root passes `--no-record`; Oracle omits both `reviewedRecord` and
 `reviewedRecordSha256`. Do not combine `--no-record` with `--record-sha256` or

package/skills/thoth-sdd/references/phases/checklist.md

@@ -1,3 +1,3 @@
 # Checklist
 
-Optional audit for risk or acceptance ambiguity after planning. Assess completeness, clarity, consistency, measurability, and relevant domain coverage in the sole substantial record. Correct gaps there and revalidate affected gates; never create a second checklist artifact. An unresolved material gap blocks implementation. Checklist is not a prerequisite to planning or tasks.
+Optional audit for risk or acceptance ambiguity after planning. Assess completeness, clarity, consistency, measurability, and relevant domain coverage in the sole substantial record. Root corrects gaps there and revalidates affected gates; never create a second checklist artifact. An unresolved material gap blocks implementation. Checklist is not a prerequisite to planning or tasks.

package/skills/thoth-sdd/references/phases/clarify.md

@@ -13,5 +13,5 @@ work, then select the recommendation after the third. Pending, unavailable,
 failed, interrupted, and host-prohibited attempts do not count. Do not fabricate
 facts or secrets; a safe deferral may preserve a human-owned choice as unresolved.
 
-Record the outcome in the one substantial record if one exists. An unresolved
+Root records the outcome in the one substantial record if one exists. An unresolved
 material decision blocks classification, planning, and implementation.

package/skills/thoth-sdd/references/phases/converge.md

@@ -1,3 +1,10 @@
 # Converge
 
-Optional after verification finds actionable defects. Root records only bounded remaining acceptance-linked work in the same substantial record; for small work, keep the in-session scope concise. Repair within settled intent, then repeat implementation and independent verification as warranted. If intent, scope, or risk materially changes, stop and reopen understanding and classification; do not widen silently. No convergence report.
+Optional after verification finds actionable defects. Root records only bounded remaining acceptance-linked work in the same substantial record; for small work, root updates the brief in-session plan (scope, owner, focused verification). Repair within settled intent as follows. If intent, scope, or risk materially changes, stop and reopen understanding and classification; do not widen silently. No convergence report.
+
+
+Plan review OKAY/REJECT judges the record; root repairs REJECT. Final verification PASS/FAIL judges the implementation.
+
+Root records remaining acceptance-linked work in the substantial record when one exists, otherwise in the brief in-session small plan; the owning Worker or Designer repairs each affected surface; root coordinates and does not repair implementation unless the user explicitly instructs direct work; even then, never self-approve and report unavailable independent review.
+
+Repeat independent verification as the change's verification level requires; substantial or materially risky work uses a fresh Oracle. Material changes in intent, scope or risk reopen understanding and planning before further implementation.

package/skills/thoth-sdd/references/phases/implement.md

@@ -2,7 +2,11 @@
 
 Use the settled small request or authorized substantial record, exact mutable
 bounds, and focused checks. Root owns user decisions and acceptance. Keep one
-writer per surface. No process tools, wrappers, reports, or temporary artifacts.
+writer per surface. Root alone writes the record; implementation writers start
+only after authorization and never write `.thoth/changes/`. For small work, root
+states a brief in-session plan (scope, owner, focused verification) before
+delegating or implementing, without creating a persistent record.
+No process tools, wrappers, reports, or temporary artifacts.
 
 ## Choose ownership, then bound the outcome
 

package/skills/thoth-sdd/references/phases/plan.md

@@ -1,3 +1,3 @@
 # Plan
 
-For substantial work, translate settled intent into a compact technical approach in the same ID-named `.thoth/changes/<id>/<id>.md` record. Capture relevant interfaces, mutable surfaces, durable deltas, dependencies, risks, and focused verification seams. Describe useful work-unit boundaries with concrete accepted inputs, produced outputs, and dependencies; identify owned writes, interface boundaries, focused checks with pass evidence, and meaningful return and stop conditions where known. Keep the approach decision-ready without writing task rows before the tasks phase. Plan validation is independent of tasks: the `plan` gate must pass before tasks exist. A later material change reopens understanding and classification. Do not make an auxiliary plan document or auto-increment package versions.
+For substantial work, root translates settled intent into a compact technical approach in the same ID-named `.thoth/changes/<id>/<id>.md` record. Capture relevant interfaces, mutable surfaces, durable deltas, dependencies, risks, and focused verification seams. Describe useful work-unit boundaries with concrete accepted inputs, produced outputs, and dependencies; identify owned writes, interface boundaries, focused checks with pass evidence, and meaningful return and stop conditions where known. Keep the approach decision-ready without writing task rows before the tasks phase. Plan validation is independent of tasks: the `plan` gate must pass before tasks exist. A later material change reopens understanding and classification. Do not make an auxiliary plan document or auto-increment package versions.

package/skills/thoth-sdd/references/phases/specify.md

@@ -1,3 +1,3 @@
 # Specify
 
-Required for every change, proportional to its impact. From accepted user intent and exploration, define concise observable outcomes, non-goals, and meaningful edge cases. Do not create a document or dispatch a specialist as a prerequisite. After all understanding steps, a substantial classification creates the sole `.thoth/changes/<id>/<id>.md` record; small work leaves no persistent record. Check `.thoth/specs/` baselines for declared durable deltas. A material ambiguity must be clarified before classification; do not invent authorization.
+Required for every change, proportional to its impact. From accepted user intent and exploration, define concise observable outcomes, non-goals, and meaningful edge cases. Do not create a document or dispatch a specialist as a prerequisite. After all understanding steps and substantial classification, root creates the sole `.thoth/changes/<id>/<id>.md` record; small work leaves no persistent record. Check `.thoth/specs/` baselines for declared durable deltas. A material ambiguity must be clarified before classification; do not invent authorization.

package/skills/thoth-sdd/references/phases/tasks.md

@@ -1,6 +1,6 @@
 # Tasks
 
-For substantial work, record only useful implementation slices in the same ID-named record. `tasks` and `ready` gates require every accepted outcome to have concrete task coverage; planning does not. Use one checkbox row per independently acceptable work unit, with the validator-compatible `- [ ] AC-n: ...` form on that row; repeat an AC number when separate units contribute to it. Keep the outcome in the row and indent its details as shown in the template: exact known entrypoints and skill paths; concrete accepted inputs and upstream dependencies; produced output; owner, owned writes and interface boundaries; focused check with observable PASS evidence; meaningful return milestone; and stop/escalation condition. Mark writes as `none` for read-only work.
+For substantial work, root records only useful implementation slices in the same ID-named record. `tasks` and `ready` gates require every accepted outcome to have concrete task coverage; planning does not. Use one checkbox row per independently acceptable work unit, with the validator-compatible `- [ ] AC-n: ...` form on that row; repeat an AC number when separate units contribute to it. Keep the outcome in the row and indent its details as shown in the template: exact known entrypoints and skill paths; concrete accepted inputs and upstream dependencies; produced output; owner, owned writes and interface boundaries; focused check with observable PASS evidence; meaningful return milestone; and stop/escalation condition. Mark writes as `none` for read-only work.
 
 Split a phase that contains separately acceptable outcomes before dispatch. Keep tiny cohesive mechanical edits together; do not fragment by file, test step, or mandatory agent phase. A dependent unit names the producer and accepted output, and starts only after root accepts it. Independent, precise Explorer questions may run in parallel within native capacity; dependent questions wait, and discovery is not repeated. Follow the specific discovery ownership policy when assigning evidence gathering.
 

package/skills/thoth-sdd/references/phases/verify.md

@@ -4,7 +4,7 @@ Every change requires final verification against accepted outcomes and actual ex
 
 For Oracle final verification of a small change without a record, require a valid delivery verdict with `mode:"no-record"`, null `record` and `recordSha256`, and `recordDigest:"none"`. Oracle omits both `reviewedRecord` and `reviewedRecordSha256`. Only in the CLI fallback, root passes `--no-record`. Do not combine `--no-record` with `--record-sha256` or plan-review. Otherwise final verification still requires both binding fields.
 
-Before requesting final Oracle for substantial work, run `node "<skill-dir>/scripts/validate.mjs" --change .thoth/changes/<id> --through verify --json`. This gate requires ready coverage, complete tasks, authorization disposition/provenance, and reviewed source digests/baselines; final-review fields, AC evidence rows, and Archive may remain placeholders. For each capability named by a durable delta, add exactly one `Source` entry for `.thoth/specs/<capability>/spec.md`: its reviewed SHA-256 when it exists, or `absent` only when no canonical file exists.
+Before requesting final Oracle for substantial work, root runs `node "<skill-dir>/scripts/validate.mjs" --change .thoth/changes/<id> --through verify --json`. This gate requires ready coverage, complete tasks, authorization disposition/provenance, and reviewed source digests/baselines; final-review fields, AC evidence rows, and Archive may remain placeholders. For each capability named by a durable delta, root adds exactly one `Source` entry for `.thoth/specs/<capability>/spec.md`: its reviewed SHA-256 when it exists, or `absent` only when no canonical file exists.
 
 Assign Oracle a `final-verification` review of the substantial record. Oracle returns exactly one fenced `thoth-result` JSON envelope as the entire final message, following the Oracle gate contract with `role: "oracle"`, `review.kind: "final-verification"`, and `review.verdict: "PASS" | "FAIL" | "BLOCKED"`. Its review includes `reviewedRecord` naming the reviewed record path and `reviewedRecordSha256` containing the 64 lowercase hex SHA-256 of exact UTF-8 record bytes preceding the case-sensitive `## Authorization` heading. PASS requires `status: "complete"` and no blocking risks. FAIL reports findings; BLOCKED is an actual inability to complete review, never a substitute for a malformed result or exhausted format repair.
 
@@ -12,10 +12,17 @@ Record equality, `mode` and `recordDigest` checks apply only to final verificati
 
 Root uses the harness-delivered `thoth-gate-verdict` under thoth-sdd **Specialist result validation**: exactly one outside the envelope fence, `valid:true`, assigned `kind:"final-verification"`, `verdict:"PASS"`, assigned `record`, `mode:"record"`, and `recordDigest:"match"`. Never re-emit the envelope to validate it. If a valid verdict reports `recordDigest:"unavailable"`, independently hash exact UTF-8 record bytes before `## Authorization` and compare with `recordSha256`; mismatch or unavailable calculation means no approval, with no validator rerun. Use the explicit compact CLI fallback only when no verdict was delivered: unchanged result, `--review-kind final-verification --record-sha256 <hex>` with the independently calculated expected prefix digest. Claude Code verdicts arrive with Subagent hand-back reports (foreground or background; `agent` is the agent id, match it to the Agent result's `agentId`) and completed foreground `Agent` results whose content carries the report. Other deliveries (e.g. background runs without hand-back) carry none; use the explicit compact CLI fallback.
 
-Root records `**Reviewer**: oracle`, `**Independent from implementer**: Yes`, `**Verdict**: PASS`, and `**Reviewed record SHA-256**` only from a validated PASS whose digest matches the current record, after judging content and confirming reviewer independence and provenance. Copy the verdict and `recordSha256` into the record (accepted CLI summary/digest in fallback); use `recordSha256` for the SHA field. Invalid results, FAIL, BLOCKED, and diagnosis/advice reviews do not authorize closeout or archive; route findings to convergence and report contract failures truthfully.
+Root records `**Reviewer**: oracle`, `**Independent from implementer**: Yes`, `**Verdict**: PASS`, and `**Reviewed record SHA-256**` only from a validated PASS whose digest matches the current record, after judging content and confirming reviewer independence and provenance. Root copies the verdict and `recordSha256` into the record (accepted CLI summary/digest in fallback); use `recordSha256` for the SHA field. Invalid results, FAIL, BLOCKED, and diagnosis/advice reviews do not authorize closeout or archive; route findings to convergence and report contract failures truthfully.
 
 Substantial records must not contain other `thoth-result` fences or `**Oracle envelope**:` marker lines anywhere in the file; write examples inline instead.
 
 Order: `verify` → fresh final Oracle → root validates and pastes → `closeout` → archive. After accepting a validated PASS, root pastes the Oracle's unchanged final-verification envelope under `**Oracle envelope**:` in the record's Verification section (post-PASS bookkeeping in Verification; no new review). Plan-review envelopes are not embedded. Closeout fails without exactly one valid PASS envelope matching the record path and prefix digest, consistent with `**Verdict**` and `**Reviewed record SHA-256**`. Preserve the envelope unchanged when archiving; archived validation accepts its original active record path. Historical archived records are not retrofitted or re-validated by this rule.
 
-After accepted review, record each outcome's concrete PASS evidence, actual checks, source SHA-256 digests, and the matched record-prefix hash. After PASS, edits confined to Authorization, Verification, or Closeout need no new review; any edit before `## Authorization` requires fresh independent review and a new digest. This allowance never waives structural checks, truthful provenance, stale-source rejection, or review of changed implementation. Recheck baselines after review; missing or stale digests/absence, missing evidence, or blockers prevent closeout and archive. Never create a verification report or evidence directory; route actionable findings to convergence.
+After accepted review, root records each outcome's concrete PASS evidence, actual checks, source SHA-256 digests, and the matched record-prefix hash. After PASS, edits confined to Authorization, Verification, or Closeout need no new review; any edit before `## Authorization` requires fresh independent review and a new digest. This allowance never waives structural checks, truthful provenance, stale-source rejection, or review of changed implementation. Recheck baselines after review; missing or stale digests/absence, missing evidence, or blockers prevent closeout and archive. Never create a verification report or evidence directory; route actionable findings to convergence.
+
+
+Plan review OKAY/REJECT judges the record; root repairs REJECT. Final verification PASS/FAIL judges the implementation.
+
+Root records remaining acceptance-linked work in the substantial record when one exists, otherwise in the brief in-session small plan; the owning Worker or Designer repairs each affected surface; root coordinates and does not repair implementation unless the user explicitly instructs direct work; even then, never self-approve and report unavailable independent review.
+
+Repeat independent verification as the change's verification level requires; substantial or materially risky work uses a fresh Oracle. Material changes in intent, scope or risk reopen understanding and planning before further implementation.

package/skills/thoth-sdd/templates/change.md

@@ -45,7 +45,8 @@ remaining fields below it. Repeat an AC number when separate units contribute
 to that acceptance outcome. The row text names one reviewable result; do not
 combine separately acceptable outcomes into a phase-sized task. Fill the
 indented fields with concrete information. For a read-only unit, write `none`
-for owned writes.
+for owned writes. Owner names the role executing the task unit; root always
+writes the record.
 
 - [ ] AC-1: TBD
   - Outcome: one result that root can accept independently