thoth-agents 0.10.0 → 0.12.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (101) hide show
  1. package/README.md +5 -3
  2. package/dist/agents/agent-config.d.ts +13 -0
  3. package/dist/agents/index.d.ts +1 -1
  4. package/dist/agents/orchestrator.d.ts +1 -1
  5. package/dist/{chunk-VHQMTZ5O.js → chunk-7F33WUSD.js} +1 -1
  6. package/dist/{chunk-RWQPMWEM.js → chunk-JLU3FSBT.js} +17 -2
  7. package/dist/chunk-MIDGZE34.js +107 -0
  8. package/dist/{chunk-RVQ6IIBR.js → chunk-NY2IPJ7V.js} +361 -118
  9. package/dist/{chunk-RN2ERZLZ.js → chunk-QOA2AETX.js} +2 -228
  10. package/dist/{chunk-6NZTNWI4.js → chunk-SEF6PFM6.js} +504 -211
  11. package/dist/cli/config-io.d.ts +2 -2
  12. package/dist/cli/index.js +92 -39
  13. package/dist/cli/install.d.ts +1 -0
  14. package/dist/cli/opencode-skill-consent.d.ts +5 -0
  15. package/dist/cli/operations/opencode.d.ts +2 -1
  16. package/dist/cli/operations/types.d.ts +1 -0
  17. package/dist/cli/owned-skills.d.ts +16 -0
  18. package/dist/cli/paths.d.ts +1 -1
  19. package/dist/cli/providers.d.ts +1 -1
  20. package/dist/cli/system.d.ts +3 -1
  21. package/dist/cli/thoth-mem-install.d.ts +10 -10
  22. package/dist/cli/tui/index.js +53 -5
  23. package/dist/cli/tui/operations.d.ts +2 -0
  24. package/dist/cli/types.d.ts +2 -4
  25. package/dist/config/loader.d.ts +1 -1
  26. package/dist/config/schema.d.ts +0 -31
  27. package/dist/harness/adapters/opencode.d.ts +1 -1
  28. package/dist/harness/core/agent-pack.d.ts +1 -0
  29. package/dist/harness/core/sdd.d.ts +6 -6
  30. package/dist/hooks/delegate-task-retry/hook.d.ts +8 -8
  31. package/dist/hooks/foreground-fallback/index.d.ts +14 -69
  32. package/dist/hooks/index.d.ts +0 -2
  33. package/dist/hooks/json-error-recovery/hook.d.ts +2 -15
  34. package/dist/hooks/oracle-gate-verdict/hook.d.ts +4 -11
  35. package/dist/index.d.ts +7 -4
  36. package/dist/index.js +822 -1421
  37. package/dist/opencode/agents.d.ts +3 -0
  38. package/dist/opencode/command.d.ts +3 -0
  39. package/dist/opencode/context.d.ts +20 -0
  40. package/dist/opencode/delegation-hooks.d.ts +3 -0
  41. package/dist/opencode/mcp.d.ts +3 -0
  42. package/dist/opencode/permission-rules.d.ts +9 -0
  43. package/dist/opencode/permissions.d.ts +3 -0
  44. package/dist/opencode/session-hooks.d.ts +3 -0
  45. package/dist/opencode/session-state.d.ts +39 -0
  46. package/dist/opencode/skills.d.ts +3 -0
  47. package/dist/opencode/tools.d.ts +3 -0
  48. package/dist/pi.js +3 -3
  49. package/dist/tools/ast-grep/cli.d.ts +1 -0
  50. package/dist/tools/ast-grep/index.d.ts +108 -2
  51. package/dist/tools/ast-grep/tools.d.ts +107 -3
  52. package/dist/tools/define-tool.d.ts +23 -0
  53. package/dist/tools/lsp/tools.d.ts +97 -5
  54. package/dist/utils/index.d.ts +0 -1
  55. package/package.json +14 -3
  56. package/pi/.thoth-agents-assets.json +2 -2
  57. package/pi/agents/thoth-designer.md +1 -1
  58. package/pi/agents/thoth-worker.md +1 -1
  59. package/plugin/.claude-plugin/.thoth-agents-plugin-assets.json +3 -3
  60. package/plugin/.claude-plugin/plugin.json +1 -1
  61. package/plugin/.codex-plugin/.thoth-agents-plugin-assets.json +3 -3
  62. package/plugin/.codex-plugin/plugin.json +1 -1
  63. package/plugin/agents/designer.md +1 -1
  64. package/plugin/agents/orchestrator.md +32 -32
  65. package/plugin/agents/worker.md +1 -1
  66. package/plugin/codex-hooks/payloads/designer.md +1 -1
  67. package/plugin/codex-hooks/payloads/root.md +32 -32
  68. package/plugin/codex-hooks/payloads/worker.md +1 -1
  69. package/plugin/skills/plan-reviewer/SKILL.md +5 -5
  70. package/plugin/skills/thoth-sdd/SKILL.md +33 -9
  71. package/plugin/skills/thoth-sdd/references/phases/checklist.md +1 -1
  72. package/plugin/skills/thoth-sdd/references/phases/clarify.md +1 -1
  73. package/plugin/skills/thoth-sdd/references/phases/converge.md +8 -1
  74. package/plugin/skills/thoth-sdd/references/phases/implement.md +5 -1
  75. package/plugin/skills/thoth-sdd/references/phases/plan.md +1 -1
  76. package/plugin/skills/thoth-sdd/references/phases/specify.md +1 -1
  77. package/plugin/skills/thoth-sdd/references/phases/tasks.md +1 -1
  78. package/plugin/skills/thoth-sdd/references/phases/verify.md +10 -3
  79. package/plugin/skills/thoth-sdd/scripts/validate-result.mjs +28 -2
  80. package/plugin/skills/thoth-sdd/templates/change.md +2 -1
  81. package/skills/plan-reviewer/SKILL.md +5 -5
  82. package/skills/thoth-sdd/SKILL.md +33 -9
  83. package/skills/thoth-sdd/references/phases/checklist.md +1 -1
  84. package/skills/thoth-sdd/references/phases/clarify.md +1 -1
  85. package/skills/thoth-sdd/references/phases/converge.md +8 -1
  86. package/skills/thoth-sdd/references/phases/implement.md +5 -1
  87. package/skills/thoth-sdd/references/phases/plan.md +1 -1
  88. package/skills/thoth-sdd/references/phases/specify.md +1 -1
  89. package/skills/thoth-sdd/references/phases/tasks.md +1 -1
  90. package/skills/thoth-sdd/references/phases/verify.md +10 -3
  91. package/skills/thoth-sdd/scripts/validate-result.mjs +28 -2
  92. package/skills/thoth-sdd/templates/change.md +2 -1
  93. package/thoth-agents.schema.json +0 -26
  94. package/dist/chunk-62L3ORXN.js +0 -30
  95. package/dist/delegation/project-id.d.ts +0 -10
  96. package/dist/hooks/auto-update-checker/checker.d.ts +0 -23
  97. package/dist/hooks/auto-update-checker/constants.d.ts +0 -11
  98. package/dist/hooks/auto-update-checker/index.d.ts +0 -17
  99. package/dist/hooks/auto-update-checker/types.d.ts +0 -22
  100. package/dist/utils/tmux-session-manager.d.ts +0 -63
  101. package/dist/utils/tmux.d.ts +0 -32
@@ -50,14 +50,14 @@ reports (foreground or background; `agent` is the agent id, match it to the Agen
50
50
  result's `agentId`) and completed foreground `Agent` results whose content carries
51
51
  the report. Other deliveries (e.g. background runs without hand-back) carry none;
52
52
  use the explicit compact CLI fallback.
53
- Copy the verdict and `recordSha256` into the record (accepted summary/digest
53
+ Root copies the verdict and `recordSha256` into the record (accepted summary/digest
54
54
  in fallback). Keep the shared one-request format-only repair budget. Root records
55
55
  plan-review `OKAY` only after these checks and judging content and provenance;
56
56
  a malformed or missing envelope is not approval.
57
- Root repairs same-intent blockers in the same record, revalidates affected gates,
58
- and uses a fresh Oracle for each round. A human-owned material blocker stops the
59
- round. Root records both review disposition and selection provenance without
60
- inventing approval. Accepted provenance is `EXPLICIT_REVIEW`, `EXPLICIT_SKIP`, or
57
+ On selected plan-review `REJECT`, root repairs the same record, reruns affected
58
+ gates and sends it to a fresh Oracle until `OKAY` or a human-owned material
59
+ blocker stops the round. Root records both review disposition and selection
60
+ provenance without inventing approval. Accepted provenance is `EXPLICIT_REVIEW`, `EXPLICIT_SKIP`, or
61
61
  `DEFAULT_REVIEW_AFTER_3`; `SKIPPED` requires explicit skip, while `OKAY` requires
62
62
  explicit review or the third-return review default. After validated `OKAY`, root preserves
63
63
  the separate Implement (Recommended) / Stop choice and separately offers it,
@@ -33,9 +33,9 @@ resolve material product, architecture, security, or destructive choices.
33
33
  ## Proportional classification
34
34
 
35
35
  - **Small** means local impact, clear intent, and low risk. Local work may touch
36
- several files within one area; file count alone never increases scope. Use
37
- test-first implementation and focused verification; create no persistent
38
- change record.
36
+ several files within one area; file count alone never increases scope.
37
+ Before delegating or implementing, root states a brief in-session plan (scope, owner, focused verification). Use test-first implementation and
38
+ focused verification; create no persistent change record.
39
39
  - **Substantial** means coordinated impact across multiple areas, cross-cutting
40
40
  contract changes, material uncertainty, or elevated failure/contract risk. A
41
41
  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.
48
48
 
49
49
  ## Ownership and decisions
50
50
 
51
+ Root is the sole record author at every stage: it creates, edits, validates and
52
+ corrects the record. During planning, specialists supply context within their
53
+ full role scope; root never assigns them to create, modify or correct SDD files.
54
+ Record authorship is coordination, not a direct-work allowance for discovery or
55
+ implementation. Implementation writers start only after authorization and never
56
+ write `.thoth/changes/`.
57
+
51
58
  Root owns user intent, scope, material decisions, classification, and final
52
59
  acceptance. Root also owns completing understanding, while the specific discovery
53
60
  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,
74
81
  acceptance, key decisions, units, risks, record path), then always offer
75
82
  `Review plan with Oracle (Recommended)` or `Proceed without review`, even when implementation was already authorized.
76
83
  Silence is never an explicit review skip; run a fresh read-only review only when
77
- selected. After a validated plan-review `OKAY`, separately offer `Implement (Recommended)` /
84
+ selected. On selected plan-review `REJECT`, root repairs the same record, reruns
85
+ affected gates and sends it to a fresh Oracle until `OKAY` or a human-owned
86
+ material blocker stops the round. After a validated plan-review `OKAY`, separately
87
+ offer `Implement (Recommended)` /
78
88
  `Stop`; prior explicit authorization remains valid, while an explicit later
79
89
  `Stop` supersedes it. Record the plan-review selection as
80
90
  `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
86
96
  user forbids delegation, perform authorized work directly but report unavailable
87
97
  independent review; never claim independent PASS or archive.
88
98
 
99
+
100
+
101
+ Plan review OKAY/REJECT judges the record; root repairs REJECT. Final verification PASS/FAIL judges the implementation.
102
+
103
+ 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.
104
+
105
+ 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.
106
+
89
107
  ## Bounded execution
90
108
 
91
109
  Root uses the harness progress tool (Pi `todo`, Claude `TodoWrite`, OpenCode
@@ -121,7 +139,7 @@ and preserve substantive handoffs across late notifications. Load the
121
139
 
122
140
  ## The sole substantial-change record
123
141
 
124
- After substantial classification, create only
142
+ After substantial classification, root creates only
125
143
  `.thoth/changes/<id>/<id>.md` from
126
144
  `<skill-dir>/templates/change.md`. Use a safe lowercase kebab-case ID; reject
127
145
  Windows-reserved names and unsafe path components. The record covers grounded
@@ -181,14 +199,20 @@ Require `valid:true` and `kind` matches the assignment. Plan review requires
181
199
 
182
200
  Record equality, `mode` and `recordDigest` checks apply only to final verification.
183
201
  See the [verify phase](references/phases/verify.md).
184
- Copy the verdict and `recordSha256` into the record when there is one; final
202
+ Root copies the verdict and `recordSha256` into the record when there is one; final
185
203
  verification uses that digest for `**Reviewed record SHA-256**`. Still judge
186
204
  scope, evidence, checks, freshness, provenance, independence, and content.
187
205
  Validation is not authorization.
188
206
 
189
207
  Delivery differs by harness: Pi attaches verdicts to completion notifications,
190
208
  `subagent_result`, and task-mode `subagent_run` (match `taskId`); OpenCode appends
191
- them to Oracle `task` output. Claude Code verdicts arrive with Subagent hand-back
209
+ them to completed foreground Oracle `subagent` tool output. OpenCode background
210
+ completions arrive automatically as `<subagent sessionID=... state="completed">`
211
+ messages without a `thoth-gate-verdict` line; root must use the explicit compact
212
+ validator fallback below. Delegate with `subagent` arguments `agent`,
213
+ `description`, `prompt`, optional `model`, `background:true` for independent work,
214
+ and `sessionID` to continue or clarify a child, including while running. No
215
+ status polling tool exists; default nesting depth is 1. Claude Code verdicts arrive with Subagent hand-back
192
216
  reports (foreground or background; `agent` is the agent id, match it to the Agent
193
217
  result's `agentId`) and completed foreground `Agent` results whose content carries
194
218
  the report. Other deliveries (e.g. background runs without hand-back) carry none;
@@ -202,7 +226,7 @@ result.
202
226
  ### Explicit compact fallback
203
227
 
204
228
  Only when no verdict was delivered (hook unavailable/untrusted, a Codex multi-agent
205
- v2 delivery, or a Claude background run without hand-back), resolve `<skill-dir>` from the installed
229
+ v2 delivery, an OpenCode background completion, or a Claude background run without hand-back), resolve `<skill-dir>` from the installed
206
230
  thoth-sdd SKILL.md directory, exactly as for `scripts/validate.mjs`, and run:
207
231
 
208
232
  ```text
@@ -216,7 +240,7 @@ to the assigned `plan-review` or `final-verification`. For record-bound final
216
240
  verification, independently calculate the expected record-prefix SHA-256 and
217
241
  pass `--record-sha256 <hex>`. Apply the same kind-specific approval checks above;
218
242
  the explicit expected digest supplies agreement if the CLI cannot read the
219
- record itself. Copy the accepted summary and digest into
243
+ record itself. Root copies the accepted summary and digest into
220
244
  the record. For Oracle final verification of a small change without a record,
221
245
  root passes `--no-record`; Oracle omits both `reviewedRecord` and
222
246
  `reviewedRecordSha256`. Do not combine `--no-record` with `--record-sha256` or
@@ -1,3 +1,3 @@
1
1
  # Checklist
2
2
 
3
- 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.
3
+ 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.
@@ -13,5 +13,5 @@ work, then select the recommendation after the third. Pending, unavailable,
13
13
  failed, interrupted, and host-prohibited attempts do not count. Do not fabricate
14
14
  facts or secrets; a safe deferral may preserve a human-owned choice as unresolved.
15
15
 
16
- Record the outcome in the one substantial record if one exists. An unresolved
16
+ Root records the outcome in the one substantial record if one exists. An unresolved
17
17
  material decision blocks classification, planning, and implementation.
@@ -1,3 +1,10 @@
1
1
  # Converge
2
2
 
3
- 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.
3
+ 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.
4
+
5
+
6
+ Plan review OKAY/REJECT judges the record; root repairs REJECT. Final verification PASS/FAIL judges the implementation.
7
+
8
+ 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.
9
+
10
+ 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.
@@ -2,7 +2,11 @@
2
2
 
3
3
  Use the settled small request or authorized substantial record, exact mutable
4
4
  bounds, and focused checks. Root owns user decisions and acceptance. Keep one
5
- writer per surface. No process tools, wrappers, reports, or temporary artifacts.
5
+ writer per surface. Root alone writes the record; implementation writers start
6
+ only after authorization and never write `.thoth/changes/`. For small work, root
7
+ states a brief in-session plan (scope, owner, focused verification) before
8
+ delegating or implementing, without creating a persistent record.
9
+ No process tools, wrappers, reports, or temporary artifacts.
6
10
 
7
11
  ## Choose ownership, then bound the outcome
8
12
 
@@ -1,3 +1,3 @@
1
1
  # Plan
2
2
 
3
- 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.
3
+ 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.
@@ -1,3 +1,3 @@
1
1
  # Specify
2
2
 
3
- 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.
3
+ 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.
@@ -1,6 +1,6 @@
1
1
  # Tasks
2
2
 
3
- 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.
3
+ 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.
4
4
 
5
5
  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.
6
6
 
@@ -4,7 +4,7 @@ Every change requires final verification against accepted outcomes and actual ex
4
4
 
5
5
  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.
6
6
 
7
- 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.
7
+ 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.
8
8
 
9
9
  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.
10
10
 
@@ -12,10 +12,17 @@ Record equality, `mode` and `recordDigest` checks apply only to final verificati
12
12
 
13
13
  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.
14
14
 
15
- 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.
15
+ 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.
16
16
 
17
17
  Substantial records must not contain other `thoth-result` fences or `**Oracle envelope**:` marker lines anywhere in the file; write examples inline instead.
18
18
 
19
19
  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.
20
20
 
21
- 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.
21
+ 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.
22
+
23
+
24
+ Plan review OKAY/REJECT judges the record; root repairs REJECT. Final verification PASS/FAIL judges the implementation.
25
+
26
+ 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.
27
+
28
+ 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.
@@ -122,12 +122,38 @@ function checkExpectations(options, issue) {
122
122
  );
123
123
  }
124
124
 
125
+ const isFenceLine = (line) => /^(?:`{3,}|~{3,})/.test(line);
126
+ const isVerdictLine = (line) => line.startsWith('thoth-gate-verdict ');
127
+
128
+ function unwrapSubagent(message, lines) {
129
+ if (!message.startsWith('<subagent ')) return message;
130
+ if (lines.at(-1) !== '</subagent>') return '';
131
+ const opener = lines.lastIndexOf('```thoth-result');
132
+ if (opener < 1) return '';
133
+ const header = lines.slice(0, opener).join('\n').trimEnd();
134
+ // Native descriptions are interpolated verbatim, not escaped attributes.
135
+ // Only structural lines and the completed-state marker are authoritative.
136
+ if (
137
+ !header.includes('state="completed"') ||
138
+ lines
139
+ .slice(0, opener)
140
+ .some((line) => isFenceLine(line) || isVerdictLine(line))
141
+ )
142
+ return '';
143
+ return lines.slice(opener, -1).join('\n').trim();
144
+ }
145
+
125
146
  function parseEnvelope(message) {
126
- const trimmed = typeof message === 'string' ? message.trim() : '';
147
+ const complete = typeof message === 'string' ? message.trim() : '';
148
+ const lines = complete.split(/\r\n|\r|\n/);
149
+ // Check structural lines in the complete delivery, including the header.
150
+ const singleEnvelope =
151
+ lines.filter(isFenceLine).length === 2 && !lines.some(isVerdictLine);
152
+ const trimmed = singleEnvelope ? unwrapSubagent(complete, lines) : '';
127
153
  const block = new RegExp(
128
154
  `^\`\`\`${contract.fence}\\r?\\n([\\s\\S]*?)\\r?\\n\`\`\`$`,
129
155
  ).exec(trimmed);
130
- if (!block || (trimmed.match(/^```.*$/gm) ?? []).length !== 2) {
156
+ if (!block) {
131
157
  return {
132
158
  issues: [
133
159
  {
@@ -45,7 +45,8 @@ remaining fields below it. Repeat an AC number when separate units contribute
45
45
  to that acceptance outcome. The row text names one reviewable result; do not
46
46
  combine separately acceptable outcomes into a phase-sized task. Fill the
47
47
  indented fields with concrete information. For a read-only unit, write `none`
48
- for owned writes.
48
+ for owned writes. Owner names the role executing the task unit; root always
49
+ writes the record.
49
50
 
50
51
  - [ ] AC-1: TBD
51
52
  - Outcome: one result that root can accept independently
@@ -298,32 +298,6 @@
298
298
  "type": "string"
299
299
  }
300
300
  },
301
- "tmux": {
302
- "type": "object",
303
- "properties": {
304
- "enabled": {
305
- "default": false,
306
- "type": "boolean"
307
- },
308
- "layout": {
309
- "default": "main-vertical",
310
- "type": "string",
311
- "enum": [
312
- "main-horizontal",
313
- "main-vertical",
314
- "tiled",
315
- "even-horizontal",
316
- "even-vertical"
317
- ]
318
- },
319
- "main_pane_size": {
320
- "default": 60,
321
- "type": "number",
322
- "minimum": 20,
323
- "maximum": 80
324
- }
325
- }
326
- },
327
301
  "fallback": {
328
302
  "type": "object",
329
303
  "properties": {
@@ -1,30 +0,0 @@
1
- // src/mcp/context7.ts
2
- var CONTEXT7_MCP_URL = "https://mcp.context7.com/mcp";
3
- var context7 = {
4
- type: "remote",
5
- url: CONTEXT7_MCP_URL,
6
- headers: process.env.CONTEXT7_API_KEY ? { CONTEXT7_API_KEY: process.env.CONTEXT7_API_KEY } : void 0,
7
- oauth: false
8
- };
9
-
10
- // src/mcp/exa.ts
11
- var exa = {
12
- type: "local",
13
- command: ["npx", "-y", "exa-mcp-server"]
14
- };
15
-
16
- // src/mcp/grep-app.ts
17
- var GREP_APP_MCP_URL = "https://mcp.grep.app";
18
- var grep_app = {
19
- type: "remote",
20
- url: GREP_APP_MCP_URL,
21
- oauth: false
22
- };
23
-
24
- export {
25
- CONTEXT7_MCP_URL,
26
- context7,
27
- exa,
28
- GREP_APP_MCP_URL,
29
- grep_app
30
- };
@@ -1,10 +0,0 @@
1
- import type { PluginInput } from '@opencode-ai/plugin';
2
- interface ProjectIdOptions {
3
- worktreeDirectory: string;
4
- projectName?: string;
5
- shell?: PluginInput['$'];
6
- timeoutMs?: number;
7
- }
8
- export declare function getProjectId(directory: string, timeoutMs?: number, projectName?: string, shell?: PluginInput['$']): Promise<string | null>;
9
- export declare function getProjectId(options: ProjectIdOptions): Promise<string | null>;
10
- export {};
@@ -1,23 +0,0 @@
1
- import type { PluginEntryInfo } from './types';
2
- /**
3
- * Extracts the update channel (latest, alpha, beta, etc.) from a version string.
4
- * @param version The version or tag to analyze.
5
- * @returns The channel name.
6
- */
7
- export declare function extractChannel(version: string | null): string;
8
- /**
9
- * Resolves the version of the plugin when running in local development mode.
10
- */
11
- export declare function getLocalDevVersion(directory: string): string | null;
12
- /**
13
- * Searches across all config locations to find the current installation entry for this plugin.
14
- */
15
- export declare function findPluginEntry(directory: string): PluginEntryInfo | null;
16
- /**
17
- * Resolves the installed version from node_modules, with memoization.
18
- */
19
- export declare function getCachedVersion(): string | null;
20
- /**
21
- * Fetches the latest version for a specific channel from the NPM registry.
22
- */
23
- export declare function getLatestVersion(channel?: string): Promise<string | null>;
@@ -1,11 +0,0 @@
1
- export declare const PACKAGE_NAME = "thoth-agents";
2
- export declare const NPM_REGISTRY_URL = "https://registry.npmjs.org/-/package/thoth-agents/dist-tags";
3
- export declare const NPM_FETCH_TIMEOUT = 5000;
4
- /** The directory used by OpenCode to cache node_modules for plugins. */
5
- export declare const CACHE_DIR: string;
6
- /** Path to this plugin's package.json within the OpenCode cache. */
7
- export declare const INSTALLED_PACKAGE_JSON: string;
8
- /** Primary OpenCode configuration file path (standard JSON). */
9
- export declare const USER_OPENCODE_CONFIG: string;
10
- /** Alternative OpenCode configuration file path (JSON with Comments). */
11
- export declare const USER_OPENCODE_CONFIG_JSONC: string;
@@ -1,17 +0,0 @@
1
- import type { PluginInput } from '@opencode-ai/plugin';
2
- import type { AutoUpdateCheckerOptions } from './types';
3
- /**
4
- * Creates an OpenCode hook that checks for plugin updates when a new session is created.
5
- * @param ctx The plugin input context.
6
- * @param options Configuration options for the update checker.
7
- * @returns A hook object for the session.created event.
8
- */
9
- export declare function createAutoUpdateCheckerHook(ctx: PluginInput, options?: AutoUpdateCheckerOptions): {
10
- event: ({ event }: {
11
- event: {
12
- type: string;
13
- properties?: unknown;
14
- };
15
- }) => void;
16
- };
17
- export type { AutoUpdateCheckerOptions } from './types';
@@ -1,22 +0,0 @@
1
- export interface NpmDistTags {
2
- latest: string;
3
- [key: string]: string;
4
- }
5
- export interface OpencodeConfig {
6
- plugin?: string[];
7
- [key: string]: unknown;
8
- }
9
- export interface PackageJson {
10
- version: string;
11
- name?: string;
12
- [key: string]: unknown;
13
- }
14
- export interface AutoUpdateCheckerOptions {
15
- showStartupToast?: boolean;
16
- }
17
- export interface PluginEntryInfo {
18
- entry: string;
19
- isPinned: boolean;
20
- pinnedVersion: string | null;
21
- configPath: string;
22
- }
@@ -1,63 +0,0 @@
1
- import type { PluginInput } from '@opencode-ai/plugin';
2
- import type { TmuxConfig } from '../config/schema';
3
- /**
4
- * Event shape for session events
5
- */
6
- interface SessionEvent {
7
- type: string;
8
- properties?: {
9
- info?: {
10
- id?: string;
11
- parentID?: string;
12
- title?: string;
13
- };
14
- sessionID?: string;
15
- status?: {
16
- type: string;
17
- };
18
- };
19
- }
20
- /**
21
- * TmuxSessionManager tracks child sessions and spawns/closes tmux panes for them.
22
- *
23
- * Uses session.status events for completion detection instead of polling.
24
- */
25
- export declare class TmuxSessionManager {
26
- private client;
27
- private tmuxConfig;
28
- private serverUrl;
29
- private sessions;
30
- private pollInterval?;
31
- private enabled;
32
- constructor(ctx: PluginInput, tmuxConfig: TmuxConfig);
33
- /**
34
- * Handle session.created events.
35
- * Spawns a tmux pane for child sessions (those with parentID).
36
- */
37
- onSessionCreated(event: SessionEvent): Promise<void>;
38
- /**
39
- * Handle session.status events for completion detection.
40
- * Uses session.status instead of deprecated session.idle.
41
- *
42
- * When a session becomes idle (completed), close its pane.
43
- */
44
- onSessionStatus(event: SessionEvent): Promise<void>;
45
- /**
46
- * Handle session.deleted events.
47
- * When a session is deleted, close its tmux pane immediately.
48
- */
49
- onSessionDeleted(event: SessionEvent): Promise<void>;
50
- private startPolling;
51
- private stopPolling;
52
- /**
53
- * Poll sessions for status updates (fallback for reliability).
54
- * Also handles timeout and missing session detection.
55
- */
56
- private pollSessions;
57
- private closeSession;
58
- /**
59
- * Clean up all tracked sessions.
60
- */
61
- cleanup(): Promise<void>;
62
- }
63
- export {};
@@ -1,32 +0,0 @@
1
- import type { TmuxConfig } from '../config/schema';
2
- /**
3
- * Reset the server availability cache (useful when server might have started)
4
- */
5
- export declare function resetServerCheck(): void;
6
- /**
7
- * Get cached tmux path, initializing if needed
8
- */
9
- export declare function getTmuxPath(): Promise<string | null>;
10
- /**
11
- * Check if we're running inside tmux
12
- */
13
- export declare function isInsideTmux(): boolean;
14
- export interface SpawnPaneResult {
15
- success: boolean;
16
- paneId?: string;
17
- }
18
- /**
19
- * Spawn a new tmux pane running `opencode attach <serverUrl> --session <sessionId>`
20
- * This connects the new TUI to the existing server so it receives streaming updates.
21
- * After spawning, applies the configured layout to auto-rebalance all panes.
22
- * Returns the pane ID so it can be closed later.
23
- */
24
- export declare function spawnTmuxPane(sessionId: string, description: string, config: TmuxConfig, serverUrl: string): Promise<SpawnPaneResult>;
25
- /**
26
- * Close a tmux pane by its ID and reapply layout to rebalance remaining panes
27
- */
28
- export declare function closeTmuxPane(paneId: string): Promise<boolean>;
29
- /**
30
- * Start background check for tmux availability
31
- */
32
- export declare function startTmuxCheck(): void;