hadara 0.2.0-rc.3 → 0.3.0-rc.1

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.3-blue">
8
+ <img alt="Published npm release" 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,31 +14,37 @@
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 prepared for operator publish:
24
24
 
25
25
  ```text
26
- hadara@0.2.0-rc.3
26
+ hadara@0.3.0-rc.1
27
27
  ```
28
28
 
29
- T-0287 prepares the source checkout for `0.2.0-rc.3` after the rc2 dogfooding findings and the T-0284 through T-0286 proof reliability hardening. `hadara@0.2.0-rc.3` is a publish candidate until an operator explicitly runs an approval-gated publish capsule. The latest npm-published release candidate remains `hadara@0.2.0-rc.2`.
29
+ Current published npm release:
30
30
 
31
- Current publish boundaries:
31
+ ```text
32
+ hadara@0.3.0-rc.0
33
+ ```
34
+
35
+ 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.
36
+
37
+ Phase 7.x labels are internal implementation phases, not npm release-candidate labels. Publishing `0.3.0-rc.1` or any later release still requires the approval-gated release path and explicit operator confirmation.
32
38
 
33
39
  | Surface | Status |
34
40
  |---|---|
35
41
  | 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
42
  | `hadara@0.2.0-rc.1` | Previous published npm RC. |
39
- | `hadara@0.2.0-rc.2` | Current published npm RC. |
40
- | `hadara@0.2.0-rc.3` | Current source publish candidate; not published by this capsule. |
41
- | GitHub Release | Secondary target, still approval-gated. |
43
+ | `hadara@0.2.0-rc.2` | Previous published npm RC. |
44
+ | `hadara@0.2.0-rc.3` | Previous published npm RC. |
45
+ | `hadara@0.3.0-rc.0` | Current published npm RC; package metadata lacks the intended discovery fields. |
46
+ | `hadara@0.3.0-rc.1` | Current publish candidate; T-0301 prepares the operator-confirmed npm publish path. |
47
+ | GitHub Release | Secondary target, approval-gated. |
42
48
  | Docker image | Deferred. |
43
49
  | PyPI/Python package | `hadara==0.2.0rc1` published preview bridge. |
44
50
  | Installer scripts / USB launchers | Deferred. |
@@ -49,23 +55,28 @@ No release command should publish, create a GitHub Release, build Docker images,
49
55
 
50
56
  Requires Node.js 22.
51
57
 
52
- Install the current published RC:
58
+ Install the latest published RC before the T-0301 publish step:
53
59
 
54
60
  ```bash
55
- npm install -g hadara@0.2.0-rc.2
61
+ npm install -g hadara@0.3.0-rc.0
62
+ hadara help
56
63
  hadara doctor --json
57
- hadara task list --json
58
- hadara tools list --json
59
64
  ```
60
65
 
61
66
  Run without a global install:
62
67
 
63
68
  ```bash
64
- npx hadara@0.2.0-rc.2 doctor --json
65
- npx hadara@0.2.0-rc.2 tools list --json
69
+ npx hadara@0.3.0-rc.0 help
70
+ npx hadara@0.3.0-rc.0 doctor --json
66
71
  ```
67
72
 
68
- After an operator publishes rc3, use `hadara@0.2.0-rc.3` in the install and npx commands above. Previous published RCs remain available on npm for comparison or rollback.
73
+ After the T-0301 npm publish helper verifies `hadara@0.3.0-rc.1` on the registry, install the new RC:
74
+
75
+ ```bash
76
+ npm install -g hadara@0.3.0-rc.1
77
+ hadara help
78
+ hadara doctor --json
79
+ ```
69
80
 
70
81
  ## What HADARA Gives You
71
82
 
@@ -74,54 +85,126 @@ After an operator publishes rc3, use `hadara@0.2.0-rc.3` in the install and npx
74
85
  | Task Capsules | Keep each unit of work scoped, evidenced, and resumable. |
75
86
  | Evidence Logs | Record public, reduced proof of validation without raw private logs. |
76
87
  | Handoff Protocol | Preserve current state for the next operator or agent. |
77
- | Policy Surfaces | Inspect command risk and release boundaries before mutation. |
78
- | CLI JSON Reports | Give agents and automation stable read models. |
88
+ | Structured Help | Separate primary lifecycle commands from diagnostics, advanced, release, UI, and integration surfaces. |
89
+ | Document Governance | Classify canonical, active, reference, historical, superseded, and archived docs. |
90
+ | Managed Markdown Safety | Patch declared generated sections with dry-run and hash guards. |
91
+ | Release Gates | Check package and release readiness through evidence-backed dry-run reports. |
79
92
  | Read-only MCP Bridge | Expose project/task/evidence state without default write tools. |
80
93
  | Dashboard and TUI | Provide local operator observation surfaces over existing read models. |
81
- | Release Gates | Check release readiness through evidence-backed dry-run reports. |
82
94
 
83
95
  HADARA is deliberately conservative. Read surfaces are broad; write and release surfaces are narrow, explicit, and evidence-oriented.
84
96
 
85
- ## Common Commands
97
+ ## Start Here
86
98
 
87
- Project and protocol health:
99
+ Ask the CLI for the workflow before choosing commands:
88
100
 
89
101
  ```bash
90
- hadara doctor --json
91
- hadara status --json
92
- hadara ops status --json
93
- hadara tools list --json
94
- hadara protocol doctor --json
95
- hadara protocol doctor --scope docs --json
102
+ hadara help
103
+ hadara help lifecycle
104
+ hadara task next --json
96
105
  ```
97
106
 
98
- Task workflow:
107
+ Use structured discovery when an agent or tool needs machine-readable command metadata:
108
+
109
+ ```bash
110
+ hadara commands --json
111
+ hadara commands --family capsule-lifecycle --json
112
+ hadara help command task.close
113
+ ```
114
+
115
+ ## Primary Capsule Lifecycle
116
+
117
+ The primary path is intentionally small:
99
118
 
100
119
  ```bash
101
120
  hadara task next --json
102
121
  hadara task create "implement a focused change" --json
103
- hadara task status --task T-0001 --json
104
- hadara task finish --task T-0001 --json
105
- hadara task finish --task T-0001 --execute --json
106
- hadara task ready --task T-0001 --level done --json
107
- hadara task close --task T-0001 --json
108
- hadara task close --task T-0001 --execute --json
109
- hadara task audit-close --task T-0001 --json
122
+ hadara task status --task T-XXXX --json
123
+ hadara evidence add-command --task T-XXXX --summary "..." --result passed --idempotency-key "command:T-XXXX:check" --json
124
+ hadara task finish --task T-XXXX --json
125
+ hadara task finish --task T-XXXX --execute --json
126
+ # Finalize Task Capsule docs and tracked state docs before closing.
127
+ hadara task ready --task T-XXXX --level done --json
128
+ hadara task close --task T-XXXX --json
129
+ hadara task close --task T-XXXX --execute --json
130
+ hadara task audit-close --task T-XXXX --json
131
+ hadara handoff suggest --task T-XXXX --json
132
+ ```
133
+
134
+ Optional workflow compression is read-only. Use it separately when you want a compact current-stage report and next recommended action:
135
+
136
+ ```bash
137
+ hadara task complete --task T-XXXX --json
110
138
  ```
111
139
 
112
- Evidence and handoff:
140
+ Important boundaries:
141
+
142
+ | Command | Boundary |
143
+ |---|---|
144
+ | `task status` | Read-only operator console. `ok:true` means the report was generated, not that the task is ready. |
145
+ | `task complete` | Optional read-only workflow compressor. It reports the current stage and next action. |
146
+ | `task finish --execute` | Writes only bounded status bookkeeping in `TASK.md` and `docs/TASK_BOARD.md`. |
147
+ | `task close --execute` | Appends close evidence only. |
148
+ | `task audit-close` | Read-only close proof audit. |
149
+
150
+ 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.
151
+
152
+ The full command semantics live in `docs/TASK_WORKFLOW_COMMANDS.md`.
153
+
154
+ ## Proof and Diagnostics
155
+
156
+ Diagnostics are useful, but they are not the primary lifecycle:
113
157
 
114
158
  ```bash
115
- hadara evidence collect --task T-0001 --json
116
- hadara evidence add-command --task T-0001 --summary "Focused validation passed." --result passed --json
159
+ hadara evidence lint --task T-0001 --json
117
160
  hadara evidence list --task T-0001 --json
118
161
  hadara proof status --task T-0001 --json
119
162
  hadara proof explain --task T-0001 --json
120
163
  hadara ci gate --mode advisory --task T-0001 --json
121
- hadara handoff suggest --task T-0001 --json
164
+ hadara ci gate --mode strict --task T-0001 --json
165
+ hadara protocol doctor --json
166
+ ```
167
+
168
+ Use strict gates before Done/close/release claims. Use advisory gates while exploring.
169
+
170
+ ## Document Governance
171
+
172
+ HADARA projects can register and classify their operating documents:
173
+
174
+ ```bash
175
+ hadara docs list --json
176
+ hadara docs doctor --json
177
+ hadara docs explain --path docs/PROJECT_STATE.md --json
178
+ hadara docs required-reading --json
179
+ ```
180
+
181
+ 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.
182
+
183
+ Docs cleanup is metadata-first:
184
+
185
+ ```bash
186
+ hadara docs mark --path docs/specs/old.md --status superseded --by docs/specs/new.md --reason "Replaced" --json
187
+ hadara docs archive --status superseded --json
188
+ ```
189
+
190
+ `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.
191
+
192
+ ## Managed Markdown Safety
193
+
194
+ HADARA can update declared managed sections only. Managed patch execution is dry-run-first and hash-guarded. User-authored prose remains outside automated writes.
195
+
196
+ ```bash
197
+ hadara docs managed list --json
198
+ hadara docs managed explain --path docs/TASK_BOARD.md --json
199
+ hadara docs patch --path docs/TASK_BOARD.md --section task-board --content-file .hadara/local/patches/task-board.md --json
200
+ hadara docs patch --path docs/TASK_BOARD.md --section task-board --content-file .hadara/local/patches/task-board.md --execute --before-hash sha256:... --json
122
201
  ```
123
202
 
124
- Release and package readiness:
203
+ Managed patch reports describe target hashes, section hashes, planned operations, and issues before any write is applied.
204
+
205
+ ## Release and Advanced Surfaces
206
+
207
+ Release/package commands are release-only surfaces, not ordinary lifecycle steps:
125
208
 
126
209
  ```bash
127
210
  hadara package smoke --dry-run --json
@@ -137,55 +220,49 @@ hadara release publish --mode dry-run --json
137
220
 
138
221
  `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.
139
222
 
140
- ## Task Capsule Lifecycle
141
-
142
- HADARA task workflow commands have distinct read/write boundaries. The full command semantics live in `docs/TASK_WORKFLOW_COMMANDS.md`.
143
-
144
- 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.
223
+ Dashboard, TUI, Hermes, MCP, installer, package, release, and run commands stay out of the primary lifecycle unless a task explicitly needs them.
145
224
 
146
- ```bash
147
- hadara task next --json
225
+ ## Safety Boundaries
148
226
 
149
- # If a matching capsule already exists:
150
- hadara task status --task T-XXXX --json
151
-
152
- # If no matching capsule exists, create one first:
153
- hadara task create "implement a focused change" --json
154
- hadara task status --task T-XXXX --json
155
-
156
- # Do the scoped work.
157
-
158
- hadara evidence add-command --task T-XXXX --summary "..." --result passed --idempotency-key "command:T-XXXX:check" --json
227
+ HADARA 0.3.0 is not:
159
228
 
160
- hadara task finish --task T-XXXX --json
161
- hadara task finish --task T-XXXX --execute --json
229
+ - a full agent runtime;
230
+ - Rack/enterprise behavior;
231
+ - automatic broad document rewriting;
232
+ - automatic historical document deletion;
233
+ - default shell execution through agents;
234
+ - default MCP write tooling;
235
+ - release or publish automation without operator approval.
162
236
 
163
- # Finalize Task Capsule docs and tracked state docs before closing.
237
+ HADARA separates portable runtime state from project-owned development state.
164
238
 
165
- hadara task ready --task T-XXXX --level done --json
239
+ Portable/local runtime state:
166
240
 
167
- # Optional workflow compression / next action preview:
168
- hadara task complete --task T-XXXX --json
241
+ ```text
242
+ data/
243
+ config/
244
+ secrets/
245
+ sessions/
246
+ logs/
247
+ audit/
248
+ cache/
249
+ exports/
250
+ ```
169
251
 
170
- hadara task close --task T-XXXX --json
171
- hadara task close --task T-XXXX --execute --json
252
+ Project-owned reproducible state:
172
253
 
173
- hadara task audit-close --task T-XXXX --json
254
+ ```text
255
+ docs/
256
+ tasks/
257
+ .hadara/
258
+ AGENTS.md
174
259
  ```
175
260
 
176
- Important distinctions:
177
-
178
- | Command | Boundary |
179
- |---|---|
180
- | `task status` | Read-only operator console. `ok:true` means the report was generated, not that the task is ready. |
181
- | `task complete` | Read-only workflow compressor. It reports the current stage and next action. |
182
- | `task finish --execute` | Writes only bounded status bookkeeping in `TASK.md` and `docs/TASK_BOARD.md`. |
183
- | `task close --execute` | Appends close evidence only. |
184
- | `task audit-close` | Read-only close proof audit. |
261
+ Portable/local state is not committed. Project docs, Task Capsules, and reduced public evidence are committed when they represent reproducible context.
185
262
 
186
- 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.
263
+ ## Development / Contributing
187
264
 
188
- ## Initialize a Project
265
+ Initialize a project:
189
266
 
190
267
  ```bash
191
268
  hadara init # default: standard
@@ -211,11 +288,7 @@ hadara init register-doc --path docs/specs/LOCAL.md --when "Local work" --purpos
211
288
  hadara init enable-integration --integration mcp --json
212
289
  ```
213
290
 
214
- `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.
215
-
216
- ## Develop from Source
217
-
218
- Use Node.js 22.
291
+ Develop from source with Node.js 22:
219
292
 
220
293
  ```bash
221
294
  npm install
@@ -237,56 +310,7 @@ Focused validation:
237
310
  npm run test:focused -- tests/unit/release-dry-run.test.ts
238
311
  ```
239
312
 
240
- ## Release Discipline
241
-
242
- HADARA release work is evidence-first.
243
-
244
- Before any npm publish:
245
-
246
- 1. Confirm the git worktree is clean.
247
- 2. Run `hadara release dry-run --json`.
248
- 3. Run `hadara release publish --mode dry-run --json`.
249
- 4. Confirm `NPM_TOKEN` presence without printing the token value.
250
- 5. Confirm the exact package version is not already on npm.
251
- 6. Generate fresh package, clean-checkout, and release-artifact evidence for the active release capsule.
252
- 7. Publish only after explicit operator approval.
253
- 8. Verify with `npm view hadara@<version> version`.
254
- 9. Attach reduced publish evidence.
255
- 10. Update release notes, Project State, Agent Handoff, and the active Task Capsule.
256
-
257
- Never write token values, private logs, raw npm output, private paths, or local machine state into committed evidence.
258
-
259
- ## Store Separation
260
-
261
- HADARA separates portable runtime state from project-owned development state.
262
-
263
- Portable/local runtime state:
264
-
265
- ```text
266
- data/
267
- config/
268
- secrets/
269
- sessions/
270
- logs/
271
- audit/
272
- cache/
273
- exports/
274
- ```
275
-
276
- Project-owned reproducible state:
277
-
278
- ```text
279
- docs/
280
- tasks/
281
- .hadara/
282
- AGENTS.md
283
- ```
284
-
285
- Portable/local state is not committed. Project docs, Task Capsules, and reduced public evidence are committed when they represent reproducible context.
286
-
287
- ## Optional / Deferred Integrations
288
-
289
- 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.
313
+ Optional integrations are not generated by `hadara init` and are not part of the default scaffold:
290
314
 
291
315
  ```bash
292
316
  hadara init enable-integration --integration hermes --execute --json
@@ -298,19 +322,6 @@ hadara mcp serve
298
322
 
299
323
  The default MCP server remains read-only. Evidence attach is opt-in, approval-recorded, and audited.
300
324
 
301
- ## Deferred
302
-
303
- These are intentionally not part of the current default runtime:
304
-
305
- - Full multi-agent scheduler/controller.
306
- - Broad MCP write tools.
307
- - Shell execution through agents.
308
- - Real provider execution as the default path.
309
- - GitHub Release automation as a default path.
310
- - Docker image publishing.
311
- - Installer scripts and USB portable launchers.
312
- - Live dashboard streaming.
313
-
314
325
  ## License
315
326
 
316
327
  HADARA is released under the MIT License. You can use, copy, modify, distribute, and build on it under the terms in `LICENSE`.
@@ -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
+ }