@hechura/noreaster-cli 0.2.3 → 0.2.4

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/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@hechura/noreaster-cli",
3
- "version": "0.2.3",
3
+ "version": "0.2.4",
4
4
  "description": "CLI for Hechura Noreaster agent API access",
5
5
  "repository": {
6
6
  "type": "git",
@@ -10,7 +10,7 @@ Use this skill for operational work in Noreaster through the official agent CLI
10
10
  ## Execution Defaults
11
11
 
12
12
  1. Prefer the published CLI:
13
- - `npx @hechura/noreaster-cli@0.2.3 <command>` or `noreaster <command>` after global install (`npm install -g @hechura/noreaster-cli@0.2.3`)
13
+ - `npx @hechura/noreaster-cli@0.2.4 <command>` or `noreaster <command>` after global install (`npm install -g @hechura/noreaster-cli@0.2.4`)
14
14
  - In this repo: `npm run agent -- <command>`
15
15
  2. Default API base URL:
16
16
  - `https://noreaster.vercel.app`
@@ -66,7 +66,7 @@ Common gates:
66
66
 
67
67
  - Feature PRD (`feature_description`) must be approved before Feature Spec (`design_spec`) can be approved
68
68
  - Feature Spec must be approved before draft-run apply creates work items
69
- - Document → `approved` requires a matching approved review
69
+ - Document → `approved` is a direct status transition (`docs transition <id> approved`); no approved review is required. Reviews remain available as an optional collaboration surface.
70
70
  - Agent document reads return `approved` docs by default; use `--include-drafts` only when intentionally working on drafts
71
71
 
72
72
  When refused, read the `gate` / `error` fields, fix the missing prerequisite, then retry.
@@ -114,7 +114,7 @@ noreaster docs update <id> --data '{"content":"...","change_summary":"Recorded d
114
114
  - Architectural decisions (technology choices, service boundaries, data model direction) go in a new ADR (`doc_type: "adr"`), not buried in an edit. Then update the affected `architecture` / `technical_design` doc to reflect it, with a `change_summary` referencing the ADR.
115
115
  - Implementation decisions that deviate from or refine an approved doc: update the governing doc's **Decision Log** / **Deviations from Spec** section with date, decision, rationale, and who decided — plus a `change_summary`.
116
116
  - Never rewrite history: use `docs revisions <id>` to inspect prior versions; corrections are new revisions, not silent replacements.
117
- - Approved docs are gated: content edits to an `approved` doc still record revisions, but status changes go through review (`reviews request` human approval). If your change invalidates an approval, say so and request re-review rather than working around it.
117
+ - Content edits to an `approved` doc still record revisions. Approval itself is a human decision made by changing the document status; if your change invalidates an approval, say so explicitly rather than working around it.
118
118
 
119
119
  ## Work Discovery
120
120
 
@@ -228,7 +228,7 @@ Empty `content` on create is seeded from the template for that `doc_type`.
228
228
  ## Quick Command Examples
229
229
 
230
230
  ```bash
231
- npm install -g @hechura/noreaster-cli@0.2.3
231
+ npm install -g @hechura/noreaster-cli@0.2.4
232
232
  noreaster skill install
233
233
  noreaster my-work
234
234
  noreaster features list --project-id <project-id>