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 +147 -147
- package/dist/cli/ci.js +28 -0
- package/dist/cli/commands.js +34 -0
- package/dist/cli/docs.js +81 -0
- package/dist/cli/evidence-json.js +10 -13
- package/dist/cli/evidence.js +23 -6
- package/dist/cli/help.js +152 -0
- package/dist/cli/init.js +134 -19
- package/dist/cli/main.js +33 -70
- package/dist/cli/proof.js +27 -0
- package/dist/core/schema.js +14 -0
- package/dist/evidence/evidence.js +150 -42
- 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/schema-index.json +77 -0
- package/dist/services/capability-registry.js +1483 -224
- package/dist/services/ci-gate.js +125 -0
- 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/proof-status.js +151 -0
- package/dist/services/release-artifact.js +50 -3
- package/dist/task/task-capsule.js +9 -3
- package/dist/task/task-close.js +6 -2
- package/dist/task/task-templates.js +2 -1
- package/package.json +1 -1
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/
|
|
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
|
|
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:
|
|
24
24
|
|
|
25
25
|
```text
|
|
26
|
-
hadara@0.
|
|
26
|
+
hadara@0.3.0-rc.0
|
|
27
27
|
```
|
|
28
28
|
|
|
29
|
-
|
|
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
|
-
|
|
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.
|
|
37
|
-
| `hadara@0.2.0-rc.
|
|
38
|
-
| `hadara@0.2.0-rc.
|
|
39
|
-
| `hadara@0.
|
|
40
|
-
| GitHub Release | Secondary target,
|
|
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
|
|
51
|
+
Install this release candidate:
|
|
52
52
|
|
|
53
53
|
```bash
|
|
54
|
-
npm install -g hadara@0.
|
|
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.
|
|
64
|
-
npx hadara@0.
|
|
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
|
-
|
|
|
77
|
-
|
|
|
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
|
-
##
|
|
82
|
+
## Start Here
|
|
85
83
|
|
|
86
|
-
|
|
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
|
-
|
|
92
|
+
Use structured discovery when an agent or tool needs machine-readable command metadata:
|
|
112
93
|
|
|
113
94
|
```bash
|
|
114
|
-
hadara
|
|
115
|
-
hadara
|
|
116
|
-
hadara
|
|
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
|
-
|
|
100
|
+
## Primary Capsule Lifecycle
|
|
133
101
|
|
|
134
|
-
|
|
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
|
-
|
|
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` |
|
|
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
|
|
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
|
-
##
|
|
139
|
+
## Proof and Diagnostics
|
|
140
|
+
|
|
141
|
+
Diagnostics are useful, but they are not the primary lifecycle:
|
|
185
142
|
|
|
186
143
|
```bash
|
|
187
|
-
hadara
|
|
188
|
-
hadara
|
|
189
|
-
hadara
|
|
190
|
-
hadara
|
|
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
|
-
|
|
153
|
+
Use strict gates before Done/close/release claims. Use advisory gates while exploring.
|
|
194
154
|
|
|
195
|
-
|
|
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
|
-
|
|
157
|
+
HADARA projects can register and classify their operating documents:
|
|
202
158
|
|
|
203
159
|
```bash
|
|
204
|
-
hadara
|
|
205
|
-
hadara
|
|
206
|
-
hadara
|
|
207
|
-
hadara
|
|
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
|
-
|
|
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
|
-
|
|
213
|
-
|
|
214
|
-
Use Node.js 22.
|
|
168
|
+
Docs cleanup is metadata-first:
|
|
215
169
|
|
|
216
170
|
```bash
|
|
217
|
-
|
|
218
|
-
|
|
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
|
-
|
|
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
|
-
|
|
227
|
-
|
|
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
|
-
|
|
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
|
-
|
|
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
|
-
|
|
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
|
-
|
|
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
|
-
|
|
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
|
-
|
|
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
|
-
|
|
212
|
+
HADARA 0.3.0 is not:
|
|
254
213
|
|
|
255
|
-
|
|
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
|
-
##
|
|
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
|
-
|
|
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
|
+
}
|
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
|
+
}
|
|
@@ -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
|
|
27
|
+
let appendResult;
|
|
29
28
|
try {
|
|
30
|
-
|
|
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
|
-
...
|
|
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
|
}
|