hadara 0.2.0-rc.2 → 0.3.0-rc.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.
package/README.md CHANGED
@@ -5,7 +5,7 @@
5
5
  </p>
6
6
 
7
7
  <p align="center">
8
- <img alt="Release candidate" src="https://img.shields.io/badge/release-0.2.0--rc.2-blue">
8
+ <img alt="Release candidate" src="https://img.shields.io/badge/npm-0.3.0--rc.0-blue">
9
9
  <img alt="Node.js" src="https://img.shields.io/badge/node-%3E%3D22-brightgreen">
10
10
  <img alt="License" src="https://img.shields.io/badge/license-MIT-lightgrey">
11
11
  </p>
@@ -14,30 +14,30 @@
14
14
 
15
15
  > Unbroken Context, Verified Development.
16
16
 
17
- HADARA is named from **Harness + Dara**. A harness safely binds and controls complex systems; Dara carries layered associations of holding, wisdom, durability, and continuity. HADARA binds non-deterministic LLM agent work into a production-oriented workflow through Task Capsules, Session Continuity, Policy Layers, Evidence Logs, and Handoff Protocols.
17
+ HADARA binds non-deterministic LLM agent work into a production-oriented workflow through Task Capsules, Session Continuity, Policy Layers, Evidence Logs, and Handoff Protocols.
18
18
 
19
19
  This repository is both the HADARA source checkout and the HADARA protocol workspace used to build it.
20
20
 
21
21
  ## Release Status
22
22
 
23
- The current source checkout targets:
23
+ Current release candidate:
24
24
 
25
25
  ```text
26
- hadara@0.2.0-rc.2
26
+ hadara@0.3.0-rc.0
27
27
  ```
28
28
 
29
- T-0282 refreshes the npm release-candidate source state for `0.2.0-rc.2` after the init scaffold protocol guidance follow-up. T-0275 published the previous `0.2.0-rc.1` RC after the installed-package recycle fixes.
29
+ The 0.3.0 line is the Phase 7 Surface Refactor. It organizes HADARA's existing task, evidence, proof, lifecycle, release, and document surfaces so agents can distinguish primary lifecycle commands, diagnostics, advanced surfaces, canonical documents, historical documents, and safe Markdown update boundaries.
30
30
 
31
- Current publish boundaries:
31
+ Phase 7.x labels are internal implementation phases, not npm release-candidate labels. Publishing `0.3.0-rc.0` or any later release still requires the approval-gated release path and explicit operator confirmation.
32
32
 
33
33
  | Surface | Status |
34
34
  |---|---|
35
35
  | npm package | Primary release target. |
36
- | `hadara@0.1.0-rc.0` | Published first RC. |
37
- | `hadara@0.2.0-rc.0` | Superseded internal publish candidate after recycle findings. |
38
- | `hadara@0.2.0-rc.1` | Current published npm RC until rc.2 is operator-published. |
39
- | `hadara@0.2.0-rc.2` | Current source version and next npm RC target. |
40
- | GitHub Release | Secondary target, still approval-gated. |
36
+ | `hadara@0.2.0-rc.1` | Previous published npm RC. |
37
+ | `hadara@0.2.0-rc.2` | Previous published npm RC. |
38
+ | `hadara@0.2.0-rc.3` | Previous published npm RC. |
39
+ | `hadara@0.3.0-rc.0` | Current release candidate. |
40
+ | GitHub Release | Secondary target, approval-gated. |
41
41
  | Docker image | Deferred. |
42
42
  | PyPI/Python package | `hadara==0.2.0rc1` published preview bridge. |
43
43
  | Installer scripts / USB launchers | Deferred. |
@@ -48,24 +48,21 @@ No release command should publish, create a GitHub Release, build Docker images,
48
48
 
49
49
  Requires Node.js 22.
50
50
 
51
- Install the current RC:
51
+ Install this release candidate:
52
52
 
53
53
  ```bash
54
- npm install -g hadara@0.2.0-rc.2
54
+ npm install -g hadara@0.3.0-rc.0
55
+ hadara help
55
56
  hadara doctor --json
56
- hadara task list --json
57
- hadara tools list --json
58
57
  ```
59
58
 
60
59
  Run without a global install:
61
60
 
62
61
  ```bash
63
- npx hadara@0.2.0-rc.2 doctor --json
64
- npx hadara@0.2.0-rc.2 tools list --json
62
+ npx hadara@0.3.0-rc.0 help
63
+ npx hadara@0.3.0-rc.0 doctor --json
65
64
  ```
66
65
 
67
- Previous published RCs: `hadara@0.2.0-rc.1` and `hadara@0.1.0-rc.0` remain available on npm for comparison or rollback, but new installs should use the current RC after the operator publishes it.
68
-
69
66
  ## What HADARA Gives You
70
67
 
71
68
  | Capability | Purpose |
@@ -73,186 +70,154 @@ Previous published RCs: `hadara@0.2.0-rc.1` and `hadara@0.1.0-rc.0` remain avail
73
70
  | Task Capsules | Keep each unit of work scoped, evidenced, and resumable. |
74
71
  | Evidence Logs | Record public, reduced proof of validation without raw private logs. |
75
72
  | Handoff Protocol | Preserve current state for the next operator or agent. |
76
- | Policy Surfaces | Inspect command risk and release boundaries before mutation. |
77
- | CLI JSON Reports | Give agents and automation stable read models. |
73
+ | Structured Help | Separate primary lifecycle commands from diagnostics, advanced, release, UI, and integration surfaces. |
74
+ | Document Governance | Classify canonical, active, reference, historical, superseded, and archived docs. |
75
+ | Managed Markdown Safety | Patch declared generated sections with dry-run and hash guards. |
76
+ | Release Gates | Check package and release readiness through evidence-backed dry-run reports. |
78
77
  | Read-only MCP Bridge | Expose project/task/evidence state without default write tools. |
79
78
  | Dashboard and TUI | Provide local operator observation surfaces over existing read models. |
80
- | Release Gates | Check release readiness through evidence-backed dry-run reports. |
81
79
 
82
80
  HADARA is deliberately conservative. Read surfaces are broad; write and release surfaces are narrow, explicit, and evidence-oriented.
83
81
 
84
- ## Common Commands
82
+ ## Start Here
85
83
 
86
- Project and protocol health:
87
-
88
- ```bash
89
- hadara doctor --json
90
- hadara status --json
91
- hadara ops status --json
92
- hadara tools list --json
93
- hadara protocol doctor --json
94
- hadara protocol doctor --scope docs --json
95
- ```
96
-
97
- Task workflow:
84
+ Ask the CLI for the workflow before choosing commands:
98
85
 
99
86
  ```bash
87
+ hadara help
88
+ hadara help lifecycle
100
89
  hadara task next --json
101
- hadara task create "implement a focused change" --json
102
- hadara task status --task T-0001 --json
103
- hadara task finish --task T-0001 --json
104
- hadara task finish --task T-0001 --execute --json
105
- hadara task ready --task T-0001 --level done --json
106
- hadara task close --task T-0001 --json
107
- hadara task close --task T-0001 --execute --json
108
- hadara task audit-close --task T-0001 --json
109
90
  ```
110
91
 
111
- Evidence and handoff:
92
+ Use structured discovery when an agent or tool needs machine-readable command metadata:
112
93
 
113
94
  ```bash
114
- hadara evidence collect --task T-0001 --json
115
- hadara evidence add-command --task T-0001 --summary "Focused validation passed." --result passed --json
116
- hadara evidence list --task T-0001 --json
117
- hadara handoff suggest --task T-0001 --json
118
- ```
119
-
120
- Release and package readiness:
121
-
122
- ```bash
123
- hadara package smoke --dry-run --json
124
- hadara package smoke --execute --attach-evidence --task T-0001 --json
125
- hadara smoke clean-checkout --execute --attach-evidence --task T-0001 --json
126
- hadara release artifact --execute --json --output dist-release --attach-evidence --task T-0001
127
- hadara release gate --mode strict --json
128
- hadara release dry-run --json
129
- hadara release publish --mode dry-run --json
95
+ hadara commands --json
96
+ hadara commands --family capsule-lifecycle --json
97
+ hadara help command task.close
130
98
  ```
131
99
 
132
- `package smoke --execute`, `smoke clean-checkout --execute`, and `release artifact --execute` create local validation artifacts and reduced public evidence only. They must not publish packages, create GitHub Releases, build Docker images, push images, or load publish token values.
100
+ ## Primary Capsule Lifecycle
133
101
 
134
- `release publish --mode dry-run` reports readiness, token presence by name, approval requirements, and mutation privacy flags without running `npm publish`. Any publish execution must happen only in a separate approval-gated release capsule with explicit operator confirmation.
135
-
136
- ## Task Capsule Lifecycle
137
-
138
- HADARA task workflow commands have distinct read/write boundaries. The full command semantics live in `docs/TASK_WORKFLOW_COMMANDS.md`.
139
-
140
- Phase 6 reports support optional actor/run metadata for future multi-agent-compatible workflows. Commands such as `task complete`, `task finish`, `task ready`, `task close`, `task audit-close`, `handoff suggest`, and `dev docker-check` may accept metadata such as `--agent-id`, `--run-id`, `--actor-role`, and `--parent-run-id`. These fields improve provenance but do not enable a scheduler or full multi-agent runtime.
102
+ The primary path is intentionally small:
141
103
 
142
104
  ```bash
143
105
  hadara task next --json
144
-
145
- # If a matching capsule already exists:
146
- hadara task status --task T-XXXX --json
147
-
148
- # If no matching capsule exists, create one first:
149
106
  hadara task create "implement a focused change" --json
150
107
  hadara task status --task T-XXXX --json
151
-
152
- # Do the scoped work.
153
-
154
- hadara evidence add-command --task T-XXXX --summary "..." --result passed --json
155
-
108
+ hadara evidence add-command --task T-XXXX --summary "..." --result passed --idempotency-key "command:T-XXXX:check" --json
156
109
  hadara task finish --task T-XXXX --json
157
110
  hadara task finish --task T-XXXX --execute --json
158
-
159
111
  # Finalize Task Capsule docs and tracked state docs before closing.
160
-
161
112
  hadara task ready --task T-XXXX --level done --json
162
-
163
- # Optional workflow compression / next action preview:
164
- hadara task complete --task T-XXXX --json
165
-
166
113
  hadara task close --task T-XXXX --json
167
114
  hadara task close --task T-XXXX --execute --json
168
-
169
115
  hadara task audit-close --task T-XXXX --json
116
+ hadara handoff suggest --task T-XXXX --json
170
117
  ```
171
118
 
172
- Important distinctions:
119
+ Optional workflow compression is read-only. Use it separately when you want a compact current-stage report and next recommended action:
120
+
121
+ ```bash
122
+ hadara task complete --task T-XXXX --json
123
+ ```
124
+
125
+ Important boundaries:
173
126
 
174
127
  | Command | Boundary |
175
128
  |---|---|
176
129
  | `task status` | Read-only operator console. `ok:true` means the report was generated, not that the task is ready. |
177
- | `task complete` | Read-only workflow compressor. It reports the current stage and next action. |
130
+ | `task complete` | Optional read-only workflow compressor. It reports the current stage and next action. |
178
131
  | `task finish --execute` | Writes only bounded status bookkeeping in `TASK.md` and `docs/TASK_BOARD.md`. |
179
132
  | `task close --execute` | Appends close evidence only. |
180
133
  | `task audit-close` | Read-only close proof audit. |
181
134
 
182
- Before `task close --execute`, finish Task Capsule docs, acceptance/tests/handoff notes, evidence summaries, Task Board updates, and tracked state docs. After close execute, changing those close-source docs intentionally invalidates the previous close proof and requires rerunning ready/close/audit. Use stable wording for close results instead of pasting volatile close evidence ids into close-source docs.
135
+ Before `task close --execute`, finish Task Capsule docs, acceptance/tests/handoff notes, evidence summaries, Task Board updates, and tracked state docs. After close execute, changing close-source docs intentionally invalidates the previous close proof and requires rerunning ready/close/audit.
136
+
137
+ The full command semantics live in `docs/TASK_WORKFLOW_COMMANDS.md`.
183
138
 
184
- ## Initialize a Project
139
+ ## Proof and Diagnostics
140
+
141
+ Diagnostics are useful, but they are not the primary lifecycle:
185
142
 
186
143
  ```bash
187
- hadara init # default: standard
188
- hadara init --profile basic
189
- hadara init --profile standard
190
- hadara init --profile governed
144
+ hadara evidence lint --task T-0001 --json
145
+ hadara evidence list --task T-0001 --json
146
+ hadara proof status --task T-0001 --json
147
+ hadara proof explain --task T-0001 --json
148
+ hadara ci gate --mode advisory --task T-0001 --json
149
+ hadara ci gate --mode strict --task T-0001 --json
150
+ hadara protocol doctor --json
191
151
  ```
192
152
 
193
- Every profile generates `docs/TASK_WORKFLOW_COMMANDS.md` so fresh projects get the current evidence, ready, finish, close, and audit-close loop.
153
+ Use strict gates before Done/close/release claims. Use advisory gates while exploring.
194
154
 
195
- | Profile | Use When |
196
- |---|---|
197
- | `basic` | Small project, only task/handoff discipline needed. |
198
- | `standard` | Default multi-session project with planning and validation docs. |
199
- | `governed` | Long-lived project with security, refactor, roadmap, or operational governance needs. |
155
+ ## Document Governance
200
156
 
201
- Init maintenance commands dry-run by default unless `--execute` is supplied:
157
+ HADARA projects can register and classify their operating documents:
202
158
 
203
159
  ```bash
204
- hadara init doctor --json
205
- hadara init upgrade --profile governed --json
206
- hadara init register-doc --path docs/specs/LOCAL.md --when "Local work" --purpose "Local spec" --json
207
- hadara init enable-integration --integration mcp --json
160
+ hadara docs list --json
161
+ hadara docs doctor --json
162
+ hadara docs explain --path docs/PROJECT_STATE.md --json
163
+ hadara docs required-reading --json
208
164
  ```
209
165
 
210
- `register-doc` can use `--require-exists` when missing referenced docs should be treated as an error. `enable-integration` registers project guidance docs only; it does not enable Hermes/MCP runtime behavior or change capability gates. `upgrade` creates missing scaffold docs and updates known generated profile metadata; it does not rewrite unrelated user-authored content.
166
+ The document registry distinguishes canonical, active, reference, historical, superseded, and archived docs. `docs required-reading` reports the effective default reading set and excludes historical, superseded, and archived docs.
211
167
 
212
- ## Develop from Source
213
-
214
- Use Node.js 22.
168
+ Docs cleanup is metadata-first:
215
169
 
216
170
  ```bash
217
- npm install
218
- npm run build
219
- node dist/cli/main.js doctor --json
220
- npm run check
171
+ hadara docs mark --path docs/specs/old.md --status superseded --by docs/specs/new.md --reason "Replaced" --json
172
+ hadara docs archive --status superseded --json
221
173
  ```
222
174
 
223
- For HADARA-dev itself, Docker is the preferred validation path because host `node_modules` on mounted workspaces can be unreliable:
175
+ `docs mark --execute` is hash-guarded and writes only `.hadara/docs-registry.json`. `docs archive` is dry-run planning only in the current implementation; it does not move or delete historical files.
176
+
177
+ ## Managed Markdown Safety
178
+
179
+ HADARA can update declared managed sections only. Managed patch execution is dry-run-first and hash-guarded. User-authored prose remains outside automated writes.
224
180
 
225
181
  ```bash
226
- npm run dev:docker-check
227
- npm run dev:docker-sync-build
182
+ hadara docs managed list --json
183
+ hadara docs managed explain --path docs/TASK_BOARD.md --json
184
+ hadara docs patch --path docs/TASK_BOARD.md --section task-board --content-file .hadara/local/patches/task-board.md --json
185
+ hadara docs patch --path docs/TASK_BOARD.md --section task-board --content-file .hadara/local/patches/task-board.md --execute --before-hash sha256:... --json
228
186
  ```
229
187
 
230
- Focused validation:
188
+ Managed patch reports describe target hashes, section hashes, planned operations, and issues before any write is applied.
189
+
190
+ ## Release and Advanced Surfaces
191
+
192
+ Release/package commands are release-only surfaces, not ordinary lifecycle steps:
231
193
 
232
194
  ```bash
233
- npm run test:focused -- tests/unit/release-dry-run.test.ts
195
+ hadara package smoke --dry-run --json
196
+ hadara package smoke --execute --attach-evidence --task T-0001 --json
197
+ hadara smoke clean-checkout --execute --attach-evidence --task T-0001 --json
198
+ hadara release artifact --execute --json --output dist-release --attach-evidence --task T-0001
199
+ hadara release gate --mode strict --json
200
+ hadara release dry-run --json
201
+ hadara release publish --mode dry-run --json
234
202
  ```
235
203
 
236
- ## Release Discipline
204
+ `package smoke --execute`, `smoke clean-checkout --execute`, and `release artifact --execute` create local validation artifacts and reduced public evidence only. They must not publish packages, create GitHub Releases, build Docker images, push images, or load publish token values.
237
205
 
238
- HADARA release work is evidence-first.
206
+ `release publish --mode dry-run` reports readiness, token presence by name, approval requirements, and mutation privacy flags without running `npm publish`. Any publish execution must happen only in a separate approval-gated release capsule with explicit operator confirmation.
239
207
 
240
- Before any npm publish:
208
+ Dashboard, TUI, Hermes, MCP, installer, package, release, and run commands stay out of the primary lifecycle unless a task explicitly needs them.
241
209
 
242
- 1. Confirm the git worktree is clean.
243
- 2. Run `hadara release dry-run --json`.
244
- 3. Run `hadara release publish --mode dry-run --json`.
245
- 4. Confirm `NPM_TOKEN` presence without printing the token value.
246
- 5. Confirm the exact package version is not already on npm.
247
- 6. Generate fresh package, clean-checkout, and release-artifact evidence for the active release capsule.
248
- 7. Publish only after explicit operator approval.
249
- 8. Verify with `npm view hadara@<version> version`.
250
- 9. Attach reduced publish evidence.
251
- 10. Update release notes, Project State, Agent Handoff, and the active Task Capsule.
210
+ ## Safety Boundaries
252
211
 
253
- Never write token values, private logs, raw npm output, private paths, or local machine state into committed evidence.
212
+ HADARA 0.3.0 is not:
254
213
 
255
- ## Store Separation
214
+ - a full agent runtime;
215
+ - Rack/enterprise behavior;
216
+ - automatic broad document rewriting;
217
+ - automatic historical document deletion;
218
+ - default shell execution through agents;
219
+ - default MCP write tooling;
220
+ - release or publish automation without operator approval.
256
221
 
257
222
  HADARA separates portable runtime state from project-owned development state.
258
223
 
@@ -280,9 +245,57 @@ AGENTS.md
280
245
 
281
246
  Portable/local state is not committed. Project docs, Task Capsules, and reduced public evidence are committed when they represent reproducible context.
282
247
 
283
- ## Optional / Deferred Integrations
248
+ ## Development / Contributing
249
+
250
+ Initialize a project:
251
+
252
+ ```bash
253
+ hadara init # default: standard
254
+ hadara init --profile basic
255
+ hadara init --profile standard
256
+ hadara init --profile governed
257
+ ```
258
+
259
+ Every profile generates `docs/TASK_WORKFLOW_COMMANDS.md` so fresh projects get the current evidence, ready, finish, close, and audit-close loop.
260
+
261
+ | Profile | Use When |
262
+ |---|---|
263
+ | `basic` | Small project, only task/handoff discipline needed. |
264
+ | `standard` | Default multi-session project with planning and validation docs. |
265
+ | `governed` | Long-lived project with security, refactor, roadmap, or operational governance needs. |
266
+
267
+ Init maintenance commands dry-run by default unless `--execute` is supplied:
268
+
269
+ ```bash
270
+ hadara init doctor --json
271
+ hadara init upgrade --profile governed --json
272
+ hadara init register-doc --path docs/specs/LOCAL.md --when "Local work" --purpose "Local spec" --json
273
+ hadara init enable-integration --integration mcp --json
274
+ ```
284
275
 
285
- Hermes and MCP surfaces exist for compatibility experiments and read-only bridge work. They are not generated by `hadara init` and are not part of the default scaffold. Use them only when a project explicitly opts into integration guidance.
276
+ Develop from source with Node.js 22:
277
+
278
+ ```bash
279
+ npm install
280
+ npm run build
281
+ node dist/cli/main.js doctor --json
282
+ npm run check
283
+ ```
284
+
285
+ For HADARA-dev itself, Docker is the preferred validation path because host `node_modules` on mounted workspaces can be unreliable:
286
+
287
+ ```bash
288
+ npm run dev:docker-check
289
+ npm run dev:docker-sync-build
290
+ ```
291
+
292
+ Focused validation:
293
+
294
+ ```bash
295
+ npm run test:focused -- tests/unit/release-dry-run.test.ts
296
+ ```
297
+
298
+ Optional integrations are not generated by `hadara init` and are not part of the default scaffold:
286
299
 
287
300
  ```bash
288
301
  hadara init enable-integration --integration hermes --execute --json
@@ -294,19 +307,6 @@ hadara mcp serve
294
307
 
295
308
  The default MCP server remains read-only. Evidence attach is opt-in, approval-recorded, and audited.
296
309
 
297
- ## Deferred
298
-
299
- These are intentionally not part of the current default runtime:
300
-
301
- - Full multi-agent scheduler/controller.
302
- - Broad MCP write tools.
303
- - Shell execution through agents.
304
- - Real provider execution as the default path.
305
- - GitHub Release automation as a default path.
306
- - Docker image publishing.
307
- - Installer scripts and USB portable launchers.
308
- - Live dashboard streaming.
309
-
310
310
  ## License
311
311
 
312
312
  HADARA is released under the MIT License. You can use, copy, modify, distribute, and build on it under the terms in `LICENSE`.
package/dist/cli/ci.js ADDED
@@ -0,0 +1,28 @@
1
+ "use strict";
2
+ Object.defineProperty(exports, "__esModule", { value: true });
3
+ exports.handleCiCommand = handleCiCommand;
4
+ const args_1 = require("./args");
5
+ const ci_gate_1 = require("../services/ci-gate");
6
+ function handleCiCommand(input) {
7
+ if (input.args[0] !== 'ci' || input.args[1] !== 'gate')
8
+ return false;
9
+ const mode = parseCiGateMode((0, args_1.getStringOption)(input.args, '--mode', 'advisory') ?? 'advisory');
10
+ const report = (0, ci_gate_1.createCiGateReport)(input.projectRoot, mode, {
11
+ taskId: (0, args_1.getStringOption)(input.args, '--task'),
12
+ allowEmpty: (0, args_1.getFlag)(input.args, '--allow-empty')
13
+ });
14
+ if (input.jsonOutput) {
15
+ console.log(JSON.stringify(report, null, 2));
16
+ }
17
+ else {
18
+ console.log(`[HADARA] ci gate ${mode}: ${report.ok ? 'ok' : 'blocked'} | blockers ${report.blockers.length} | warnings ${report.warnings.length}`);
19
+ }
20
+ if (!report.ok)
21
+ process.exitCode = 6;
22
+ return true;
23
+ }
24
+ function parseCiGateMode(value) {
25
+ if (value === 'advisory' || value === 'strict')
26
+ return value;
27
+ throw new Error(`unsupported ci gate mode: ${value}`);
28
+ }
@@ -0,0 +1,34 @@
1
+ "use strict";
2
+ Object.defineProperty(exports, "__esModule", { value: true });
3
+ exports.handleCommandsCommand = handleCommandsCommand;
4
+ exports.createCommandsRegistryReport = createCommandsRegistryReport;
5
+ const args_1 = require("./args");
6
+ const capability_registry_1 = require("../services/capability-registry");
7
+ function handleCommandsCommand(input) {
8
+ const family = (0, args_1.getStringOption)(input.args, '--family');
9
+ const requiredness = (0, args_1.getStringOption)(input.args, '--requiredness');
10
+ const report = createCommandsRegistryReport({ family, requiredness });
11
+ if (input.jsonOutput) {
12
+ console.log(JSON.stringify(report, null, 2));
13
+ }
14
+ else {
15
+ for (const entry of report.commands) {
16
+ console.log(`${entry.id} | ${entry.family} | ${entry.requiredness} | ${entry.command}`);
17
+ }
18
+ }
19
+ return true;
20
+ }
21
+ function createCommandsRegistryReport(filters = {}) {
22
+ return {
23
+ schemaVersion: 'hadara.commands.registry.v1',
24
+ command: 'commands',
25
+ ok: true,
26
+ registryVersion: capability_registry_1.HADARA_COMMAND_REGISTRY_VERSION,
27
+ filters: {
28
+ family: filters.family ?? null,
29
+ requiredness: filters.requiredness ?? null
30
+ },
31
+ commands: (0, capability_registry_1.listCommandRegistryEntries)(filters),
32
+ issues: []
33
+ };
34
+ }
@@ -0,0 +1,81 @@
1
+ "use strict";
2
+ Object.defineProperty(exports, "__esModule", { value: true });
3
+ exports.handleDocsCommand = handleDocsCommand;
4
+ const args_1 = require("./args");
5
+ const docs_cleanup_1 = require("../services/docs-cleanup");
6
+ const docs_registry_1 = require("../services/docs-registry");
7
+ const managed_sections_1 = require("../services/managed-sections");
8
+ function handleDocsCommand(input) {
9
+ const sub = input.args[1];
10
+ if (sub === 'list') {
11
+ const report = (0, docs_registry_1.createDocsListReport)(input.projectRoot, {
12
+ status: (0, args_1.getStringOption)(input.args, '--status'),
13
+ readWhen: (0, args_1.getStringOption)(input.args, '--read-when')
14
+ });
15
+ printReport(report, input.jsonOutput);
16
+ return true;
17
+ }
18
+ if (sub === 'doctor') {
19
+ const report = (0, docs_registry_1.createDocsDoctorReport)(input.projectRoot, (0, args_1.getStringOption)(input.args, '--scope', 'all') ?? 'all');
20
+ printReport(report, input.jsonOutput);
21
+ return true;
22
+ }
23
+ if (sub === 'explain') {
24
+ const documentPath = (0, args_1.getStringOption)(input.args, '--path') ?? input.args[2] ?? '';
25
+ const report = (0, docs_registry_1.createDocsExplainReport)(input.projectRoot, documentPath);
26
+ printReport(report, input.jsonOutput);
27
+ return true;
28
+ }
29
+ if (sub === 'managed') {
30
+ const managedSub = input.args[2];
31
+ if (managedSub === 'list') {
32
+ printReport((0, managed_sections_1.createManagedSectionsListReport)(input.projectRoot), input.jsonOutput);
33
+ return true;
34
+ }
35
+ if (managedSub === 'explain') {
36
+ printReport((0, managed_sections_1.createManagedSectionExplainReport)(input.projectRoot, (0, args_1.getRequiredStringOption)(input.args, '--path')), input.jsonOutput);
37
+ return true;
38
+ }
39
+ }
40
+ if (sub === 'patch') {
41
+ const report = (0, managed_sections_1.createDocsPatchPlanReport)(input.projectRoot, {
42
+ targetPath: (0, args_1.getRequiredStringOption)(input.args, '--path'),
43
+ sectionId: (0, args_1.getRequiredStringOption)(input.args, '--section'),
44
+ contentFile: (0, args_1.getRequiredStringOption)(input.args, '--content-file'),
45
+ mode: (0, args_1.getFlag)(input.args, '--execute') ? 'execute' : 'dry-run',
46
+ beforeHash: (0, args_1.getStringOption)(input.args, '--before-hash'),
47
+ owner: (0, args_1.getStringOption)(input.args, '--owner', 'operator') ?? 'operator'
48
+ });
49
+ printReport(report, input.jsonOutput);
50
+ return true;
51
+ }
52
+ if (sub === 'mark') {
53
+ const report = (0, docs_cleanup_1.createDocsMarkReport)(input.projectRoot, {
54
+ documentPath: (0, args_1.getRequiredStringOption)(input.args, '--path'),
55
+ status: (0, args_1.getRequiredStringOption)(input.args, '--status'),
56
+ reason: (0, args_1.getStringOption)(input.args, '--reason'),
57
+ by: (0, args_1.getStringOption)(input.args, '--by'),
58
+ mode: (0, args_1.getFlag)(input.args, '--execute') ? 'execute' : 'dry-run',
59
+ beforeHash: (0, args_1.getStringOption)(input.args, '--before-hash'),
60
+ forceCanonical: (0, args_1.getFlag)(input.args, '--force-canonical')
61
+ });
62
+ printReport(report, input.jsonOutput);
63
+ return true;
64
+ }
65
+ if (sub === 'archive') {
66
+ printReport((0, docs_cleanup_1.createDocsArchivePlanReport)(input.projectRoot, (0, args_1.getStringOption)(input.args, '--status')), input.jsonOutput);
67
+ return true;
68
+ }
69
+ if (sub === 'required-reading') {
70
+ printReport((0, docs_cleanup_1.createDocsRequiredReadingReport)(input.projectRoot), input.jsonOutput);
71
+ return true;
72
+ }
73
+ return false;
74
+ }
75
+ function printReport(report, jsonOutput) {
76
+ if (jsonOutput) {
77
+ console.log(JSON.stringify(report, null, 2));
78
+ return;
79
+ }
80
+ console.log(JSON.stringify(report, null, 2));
81
+ }
@@ -4,7 +4,6 @@ var __importDefault = (this && this.__importDefault) || function (mod) {
4
4
  };
5
5
  Object.defineProperty(exports, "__esModule", { value: true });
6
6
  exports.createEvidenceCollectReport = createEvidenceCollectReport;
7
- const node_fs_1 = __importDefault(require("node:fs"));
8
7
  const node_path_1 = __importDefault(require("node:path"));
9
8
  const evidence_1 = require("../evidence/evidence");
10
9
  const task_capsule_1 = require("../task/task-capsule");
@@ -25,19 +24,20 @@ function createEvidenceCollectReport(projectRoot, input) {
25
24
  ]
26
25
  };
27
26
  }
28
- let markdownPath;
27
+ let appendResult;
29
28
  try {
30
- markdownPath = (0, evidence_1.appendEvidence)(projectRoot, {
29
+ appendResult = (0, evidence_1.appendEvidenceWithResult)(projectRoot, {
31
30
  taskId: input.taskId,
32
31
  kind: input.kind,
33
32
  path: input.path,
34
33
  summary: input.summary,
35
34
  result: input.result,
36
- visibility: input.visibility
35
+ visibility: input.visibility,
36
+ idempotencyKey: input.idempotencyKey
37
37
  });
38
38
  }
39
39
  catch (error) {
40
- if (error instanceof workspace_1.WorkspaceFileError || error instanceof evidence_1.EvidenceArtifactPolicyError) {
40
+ if (error instanceof workspace_1.WorkspaceFileError || error instanceof evidence_1.EvidenceArtifactPolicyError || error instanceof evidence_1.EvidenceAppendLockError) {
41
41
  return {
42
42
  schemaVersion: 'hadara.evidence.collect.v1',
43
43
  command: 'evidence.collect',
@@ -53,23 +53,20 @@ function createEvidenceCollectReport(projectRoot, input) {
53
53
  }
54
54
  throw error;
55
55
  }
56
- const indexRecord = readLastEvidenceIndexRecord(task.dir);
57
56
  return {
58
57
  schemaVersion: 'hadara.evidence.collect.v1',
59
58
  command: 'evidence.collect',
60
59
  ok: true,
61
60
  evidence: {
62
- ...indexRecord,
63
- markdownPath: toPortablePath(node_path_1.default.relative(projectRoot, markdownPath))
61
+ ...appendResult.evidence,
62
+ markdownPath: toPortablePath(node_path_1.default.relative(projectRoot, appendResult.markdownPath)),
63
+ markdownAppended: appendResult.markdownAppended,
64
+ jsonlAppended: appendResult.jsonlAppended,
65
+ existing: appendResult.existing
64
66
  },
65
67
  issues: []
66
68
  };
67
69
  }
68
- function readLastEvidenceIndexRecord(taskDir) {
69
- const indexPath = node_path_1.default.join(taskDir, 'evidence.jsonl');
70
- const lines = node_fs_1.default.readFileSync(indexPath, 'utf8').trim().split(/\r?\n/);
71
- return JSON.parse(lines.at(-1) ?? '{}');
72
- }
73
70
  function toPortablePath(value) {
74
71
  return value.split(node_path_1.default.sep).join('/');
75
72
  }