@hechura/noreaster-cli 0.2.2 → 0.2.4

package/dist/document-templates.js

@@ -16,6 +16,7 @@ exports.TEMPLATE_DOC_TYPES = [
     "feature_summary",
     "sprint_plan",
     "executive_summary",
+    "rules",
 ];
 const AI_WRITING_HINT = `<!-- Writing for AI tools:
      - Be explicit with exact values ("max file size: 10MB", not "reasonable").
@@ -436,6 +437,39 @@ ${AI_WRITING_HINT}
 
 ## Next Steps
 
+-
+`;
+const RULES_TEMPLATE = `# Project Rules
+
+${AI_WRITING_HINT}
+
+## Purpose
+
+<!-- Binding constraints for agents implementing work in this project.
+     Prefer exact, enforceable rules over vibes. -->
+
+## Must
+
+- Agents must [specific required behavior].
+
+## Must Not
+
+- Agents must not [specific forbidden behavior].
+
+## Coding Standards
+
+- Language / framework conventions:
+- File and module layout:
+- Testing expectations:
+
+## Constraints
+
+| Constraint | Rationale |
+|------------|-----------|
+| | |
+
+## Open Questions
+
 -
 `;
 const TEMPLATES = {
@@ -450,6 +484,7 @@ const TEMPLATES = {
     feature_summary: FEATURE_SUMMARY_TEMPLATE,
     sprint_plan: SPRINT_PLAN_TEMPLATE,
     executive_summary: EXECUTIVE_SUMMARY_TEMPLATE,
+    rules: RULES_TEMPLATE,
 };
 function isTemplateDocType(value) {
     return value != null && exports.TEMPLATE_DOC_TYPES.includes(value);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@hechura/noreaster-cli",
-  "version": "0.2.2",
+  "version": "0.2.4",
   "description": "CLI for Hechura Noreaster agent API access",
   "repository": {
     "type": "git",

package/skills/hechura-manager-noreaster/SKILL.md

@@ -10,7 +10,7 @@ Use this skill for operational work in Noreaster through the official agent CLI
 ## Execution Defaults
 
 1. Prefer the published CLI:
-   - `npx @hechura/noreaster-cli@0.2.2 <command>` or `noreaster <command>` after global install (`npm install -g @hechura/noreaster-cli@0.2.2`)
+   - `npx @hechura/noreaster-cli@0.2.4 <command>` or `noreaster <command>` after global install (`npm install -g @hechura/noreaster-cli@0.2.4`)
    - In this repo: `npm run agent -- <command>`
 2. Default API base URL:
    - `https://noreaster.vercel.app`
@@ -36,6 +36,7 @@ Project documents are the versioned source of truth for how a project is built.
 
 | UI label | `doc_type` | Purpose — how agents use it |
 | --- | --- | --- |
+| Rules | `rules` | Binding agent execution constraints for the project (must / must-not, coding standards). **Always load and apply before implementing work items.** |
 | PRD | `prd` | Product requirements: problem, goals, personas, feature list. Governs *what* to build and why. |
 | Architecture | `architecture` | System overview: services, data flows, infrastructure. Governs *where* code lives and how systems connect. |
 | Technical Design | `technical_design` | Project-level technical design: affected areas, API contracts, data model, edge cases. Governs implementation shape. |
@@ -65,7 +66,7 @@ Common gates:
 
 - Feature PRD (`feature_description`) must be approved before Feature Spec (`design_spec`) can be approved
 - Feature Spec must be approved before draft-run apply creates work items
-- Document → `approved` requires a matching approved review
+- Document → `approved` is a direct status transition (`docs transition <id> approved`); no approved review is required. Reviews remain available as an optional collaboration surface.
 - Agent document reads return `approved` docs by default; use `--include-drafts` only when intentionally working on drafts
 
 When refused, read the `gate` / `error` fields, fix the missing prerequisite, then retry.
@@ -77,6 +78,7 @@ Before implementing a work item, load the governing docs — do not invent contr
 1. Fetch the work item: `tasks get <id>`
 2. Follow `source_document_id` (or the feature's Feature Spec / `design_spec`) and read it: `docs get <id>`
 3. Load project foundation docs:
+   - `docs list --project-id <id> --type rules` — **apply these Rules when implementing**; treat Must / Must Not as binding
    - `docs list --project-id <id> --type architecture`
    - `docs list --project-id <id> --type design_system`
    - `docs list --project-id <id> --type technical_design`
@@ -85,6 +87,7 @@ Before implementing a work item, load the governing docs — do not invent contr
 
 Compliance rules while coding:
 
+- Honor project Rules (`doc_type: rules`) — do not violate Must / Must Not or coding standards
 - Honor the Feature Spec's API contract and data model verbatim
 - Every edge-case table row becomes a required test
 - UI work must conform to the approved design-system doc (tokens, components, a11y)
@@ -111,7 +114,7 @@ noreaster docs update <id> --data '{"content":"...","change_summary":"Recorded d
 - 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.
 - 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`.
 - Never rewrite history: use `docs revisions <id>` to inspect prior versions; corrections are new revisions, not silent replacements.
-- 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.
+- 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.
 
 ## Work Discovery
 
@@ -225,7 +228,7 @@ Empty `content` on create is seeded from the template for that `doc_type`.
 ## Quick Command Examples
 
 ```bash
-npm install -g @hechura/noreaster-cli@0.2.2
+npm install -g @hechura/noreaster-cli@0.2.4
 noreaster skill install
 noreaster my-work
 noreaster features list --project-id <project-id>