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 +158 -147
- package/dist/cli/commands.js +34 -0
- package/dist/cli/docs.js +81 -0
- package/dist/cli/help.js +152 -0
- package/dist/cli/init.js +128 -13
- package/dist/cli/main.js +21 -73
- package/dist/cli/protocol.js +37 -0
- package/dist/core/schema.js +16 -0
- package/dist/schemas/docs-archive-plan.schema.json +69 -0
- package/dist/schemas/docs-doctor.schema.json +45 -0
- package/dist/schemas/docs-explain.schema.json +69 -0
- package/dist/schemas/docs-list.schema.json +75 -0
- package/dist/schemas/docs-mark.schema.json +65 -0
- package/dist/schemas/docs-patch-plan.schema.json +64 -0
- package/dist/schemas/docs-required-reading.schema.json +63 -0
- package/dist/schemas/protocol-migration.schema.json +111 -0
- package/dist/schemas/schema-index.json +84 -0
- package/dist/services/capability-registry.js +1508 -224
- package/dist/services/docs-cleanup.js +207 -0
- package/dist/services/docs-registry.js +312 -0
- package/dist/services/lifecycle-guide.js +185 -0
- package/dist/services/managed-sections.js +303 -0
- package/dist/services/protocol-migration.js +396 -0
- package/dist/services/release-artifact.js +50 -3
- package/dist/task/task-capsule.js +9 -3
- package/dist/task/task-finish.js +7 -0
- package/dist/task/task-templates.js +2 -1
- package/package.json +26 -2
package/README.md
CHANGED
|
@@ -5,7 +5,7 @@
|
|
|
5
5
|
</p>
|
|
6
6
|
|
|
7
7
|
<p align="center">
|
|
8
|
-
<img alt="
|
|
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
|
|
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
|
-
|
|
23
|
+
Current release candidate prepared for operator publish:
|
|
24
24
|
|
|
25
25
|
```text
|
|
26
|
-
hadara@0.
|
|
26
|
+
hadara@0.3.0-rc.1
|
|
27
27
|
```
|
|
28
28
|
|
|
29
|
-
|
|
29
|
+
Current published npm release:
|
|
30
30
|
|
|
31
|
-
|
|
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` |
|
|
40
|
-
| `hadara@0.2.0-rc.3` |
|
|
41
|
-
|
|
|
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
|
|
58
|
+
Install the latest published RC before the T-0301 publish step:
|
|
53
59
|
|
|
54
60
|
```bash
|
|
55
|
-
npm install -g hadara@0.
|
|
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.
|
|
65
|
-
npx hadara@0.
|
|
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
|
|
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
|
-
|
|
|
78
|
-
|
|
|
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
|
-
##
|
|
97
|
+
## Start Here
|
|
86
98
|
|
|
87
|
-
|
|
99
|
+
Ask the CLI for the workflow before choosing commands:
|
|
88
100
|
|
|
89
101
|
```bash
|
|
90
|
-
hadara
|
|
91
|
-
hadara
|
|
92
|
-
hadara
|
|
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
|
-
|
|
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-
|
|
104
|
-
hadara
|
|
105
|
-
hadara task finish --task T-
|
|
106
|
-
hadara task
|
|
107
|
-
|
|
108
|
-
hadara task
|
|
109
|
-
hadara task
|
|
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
|
-
|
|
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
|
|
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
|
|
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
|
-
|
|
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
|
-
|
|
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
|
-
|
|
147
|
-
hadara task next --json
|
|
225
|
+
## Safety Boundaries
|
|
148
226
|
|
|
149
|
-
|
|
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
|
-
|
|
161
|
-
|
|
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
|
-
|
|
237
|
+
HADARA separates portable runtime state from project-owned development state.
|
|
164
238
|
|
|
165
|
-
|
|
239
|
+
Portable/local runtime state:
|
|
166
240
|
|
|
167
|
-
|
|
168
|
-
|
|
241
|
+
```text
|
|
242
|
+
data/
|
|
243
|
+
config/
|
|
244
|
+
secrets/
|
|
245
|
+
sessions/
|
|
246
|
+
logs/
|
|
247
|
+
audit/
|
|
248
|
+
cache/
|
|
249
|
+
exports/
|
|
250
|
+
```
|
|
169
251
|
|
|
170
|
-
|
|
171
|
-
hadara task close --task T-XXXX --execute --json
|
|
252
|
+
Project-owned reproducible state:
|
|
172
253
|
|
|
173
|
-
|
|
254
|
+
```text
|
|
255
|
+
docs/
|
|
256
|
+
tasks/
|
|
257
|
+
.hadara/
|
|
258
|
+
AGENTS.md
|
|
174
259
|
```
|
|
175
260
|
|
|
176
|
-
|
|
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
|
-
|
|
263
|
+
## Development / Contributing
|
|
187
264
|
|
|
188
|
-
|
|
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
|
-
|
|
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
|
-
|
|
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
|
+
}
|
package/dist/cli/docs.js
ADDED
|
@@ -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
|
+
}
|