@manhd_d/ai-harness 0.11.0 → 0.12.0

package/CHANGELOG.md

@@ -1,5 +1,15 @@
 # Changelog
 
+## Unreleased
+
+### Added
+- Continuous development workflow: fresh baselines, proportional cross-role impact, selective living documentation and source-policy proposals, feedback triage and session handoff.
+- Seven Core behavioral scenarios plus a cross-capability scenario, installation/update preservation coverage and package checks.
+
+### Changed
+- Existing Core/Product/Architecture/Delivery skills and OpenSpec templates retain stable IDs and distinguish implementation, merge and release evidence.
+- Product 1.5.0, Architecture/Delivery 1.1.0; no new runtime, CLI commands or config schemas. Distribution version and release automation remain unchanged.
+
 ## Unreleased — Adaptive verification and TechSpec
 - Add read-only adaptive discovery and digest/pointer-based requirement evidence validation; preserve advisory verify behavior.
 - Add Core verification and Product 1.4.0 selective TechSpec maintenance using existing artifact routes/policies.
@@ -115,6 +125,13 @@
 - Check release metadata consistency and establish single-release-PR version discipline; retain v0.6.0 until a dedicated release PR.
 
 
+## [0.12.0](https://github.com/manh0303/ai-harness/compare/v0.11.0...v0.12.0) (2026-10-13)
+
+
+### Features
+
+* continuous development and living documentation ([e87f007](https://github.com/manh0303/ai-harness/commit/e87f007c31a4a0d99f98b47f75c00ff632d92023))
+
 ## [0.11.0](https://github.com/manh0303/ai-harness/compare/v0.10.0...v0.11.0) (2026-10-13)
 
 

package/README.md

@@ -52,4 +52,4 @@ If `--detect` cannot identify the stack, [select modules explicitly](docs/gettin
 
 [Contributing](CONTRIBUTING.md) · [Harness maintenance](docs/harness-maintenance.md) · [MIT](LICENSE).
 
-[Adaptive verification & TechSpec](docs/adaptive-verification.md): project-aware plans, requirement-linked evidence and selective docs.
+[Continuous development](docs/continuous-development.md) · [Adaptive verification & TechSpec](docs/adaptive-verification.md): successive changes, current context and selective docs.

package/capabilities/architecture/capability.json

@@ -26,7 +26,7 @@
     "workflows/discovery-to-design.md",
     "workflows/change-review.md"
   ],
-  "module_version": "1.0.0",
+  "module_version": "1.1.0",
   "recommends": [
     "capability:product"
   ],

package/capabilities/architecture/checks/verification.json

@@ -24,6 +24,17 @@
         "Configured checks vs manual/unavailable verification"
       ],
       "execution": "manual"
+    },
+    {
+      "id": "continuous-maintenance",
+      "title": "Continuous change review",
+      "command": [],
+      "when_file": null,
+      "evidence": [
+        "Current code/map/ADR revisions and authority decision for drift",
+        "Affected data/API/event consumers, NFR and compatibility/regression impact"
+      ],
+      "execution": "manual"
     }
   ]
 }

package/capabilities/architecture/evals/cases.json

@@ -30,6 +30,16 @@
         "Updates affected context only on verified facts or reviewed decisions and preserves history"
       ],
       "critical": true
+    },
+    {
+      "id": "continuous-drift",
+      "prompt": "Approved BR-003 says retention 30 days; current code uses 60; a draft says 90. Fix the inconsistency; no accepted decision resolves the conflict.",
+      "criteria": [
+        "Cites conflicting source anchors/revisions and distinguishes approved/draft/superseded status",
+        "Identifies authority/owner and resolves disputed intent before editing that behavior rather than choosing code or docs silently",
+        "Continues independent authorized work and records conflict/blocker in existing decisions/impact"
+      ],
+      "critical": true
     }
   ]
 }

package/capabilities/architecture/skills/harness-architecture-change-impact/SKILL.md

@@ -41,3 +41,8 @@ Follow Core permissions, clarification and project-conventions. Ask only consequ
 2–3 distinct options, evidence-based recommendation and free text; reuse established answers.
 No invented source, measured result, target, estimate or approval. No external messaging/publishing,
 paid tool use or production changes beyond the user's explicit authorization.
+
+## Session continuity
+Use Core `continuous-development.md` to compare map, requirements/ADRs, code and evidence revisions
+with the prior handoff. Record drift with both source anchors and authority/owner; do not choose code
+or docs by recency alone. Refresh only touched map/contract/ADR sections after reconciliation.

package/capabilities/architecture/templates/project-map.md

@@ -24,3 +24,8 @@ Refresh the touched entries; do not regenerate the entire project for every task
 ## Review and handoff
 Record actual owner decisions, unresolved consequential questions, verification performed/skipped,
 next role, source/output paths and affected OpenSpec change. Draft text is not an accepted decision.
+
+## Resume reconciliation
+Compare previous verified revisions with current touched source/working-tree changes. Link the active
+OpenSpec baseline, stale assumptions/evidence, authority decision and pending refresh; do not copy
+change-level progress into a second log.

package/capabilities/architecture/workflows/change-review.md

@@ -10,3 +10,5 @@ updated affected context and explicit residual risk.
 5. Use harness-architecture-review on design/diff with actual lint/test/build/boundary evidence.
    State manual-only checks, skipped environments and author-vs-independent review explicitly.
 6. Handoff findings, source paths, decisions, IDs, pending work and next owner; release follows DevOps.
+
+Enter via Core `continuous-development.md` to reconcile the current baseline with the previous handoff. Record remaining work and separate implementation, merge and release evidence in the existing change; feedback stays proposed until an owner accepts scope.

package/capabilities/delivery/capability.json

@@ -19,7 +19,7 @@
     "workflows/planning.md",
     "workflows/execution-change.md"
   ],
-  "module_version": "1.0.0",
+  "module_version": "1.1.0",
   "recommends": [
     "capability:product",
     "capability:architecture"

package/capabilities/delivery/checks/verification.json

@@ -24,6 +24,17 @@
         "No invented schedule, progress or stakeholder messaging"
       ],
       "execution": "manual"
+    },
+    {
+      "id": "continuous-maintenance",
+      "title": "Continuous change review",
+      "command": [],
+      "when_file": null,
+      "evidence": [
+        "Actual progress/dependency/risk evidence and remaining work",
+        "Implementation complete, merged and released separate; no invented dates"
+      ],
+      "execution": "manual"
     }
   ]
 }

package/capabilities/delivery/evals/cases.json

@@ -20,6 +20,16 @@
         "Records actual owner answer before affected implementation and updates traceability/plan"
       ],
       "critical": true
+    },
+    {
+      "id": "continuous-resume",
+      "prompt": "Continue change X. Its handoff says code A and FR-002 rev 2 with PASS at A. Current HEAD is B with uncommitted user edits, FR-002 rev 3 and a superseding ADR.",
+      "criteria": [
+        "Re-reads current code/docs/ADR and working tree instead of trusting old summary",
+        "Reconciles changed assumptions and re-runs affected impact/checks; does not reuse old PASS as current proof",
+        "Preserves user edits and updates existing tasks/design/map with evidence and next step instead of a new context store"
+      ],
+      "critical": true
     }
   ]
 }

package/capabilities/delivery/skills/harness-delivery-scope-change/SKILL.md

@@ -41,3 +41,9 @@ Follow Core permissions, clarification and project-conventions. Ask only consequ
 2–3 distinct options, evidence-based recommendation and free text; reuse established answers.
 No invented source, measured result, target, estimate or approval. No external messaging/publishing,
 paid tool use or production changes beyond the user's explicit authorization.
+
+## Feedback and evidence
+Use Core `continuous-development.md` for proposed feedback vs accepted scope and session continuity.
+Update dependencies, risks and plan progress from actual evidence. Track implementation complete,
+merged and released separately with PR/release references; absent evidence stays unknown. Store
+remaining work and next action in existing change tasks, without another progress registry.

package/capabilities/delivery/workflows/execution-change.md

@@ -7,3 +7,5 @@
 4. Update affected plan, requirements, ADRs and OpenSpec only after the actual decision; keep history.
 5. Produce a status draft with completed/pending/blocked work and evidence. Release ownership/gates
    remain in DevOps; PM proposals do not approve delivery or production changes.
+
+Enter via Core `continuous-development.md` to reconcile the current baseline with the previous handoff. Record remaining work and separate implementation, merge and release evidence in the existing change; feedback stays proposed until an owner accepts scope.

package/capabilities/product/capability.json

@@ -57,7 +57,7 @@
     "templates/outcomes.md",
     "templates/techspec.md"
   ],
-  "module_version": "1.4.0",
+  "module_version": "1.5.0",
   "verification": "checks/verification.json",
   "evaluation": "evals/cases.json"
 }

package/capabilities/product/checks/verification.json

@@ -60,6 +60,17 @@
         "Static UNVERIFIED claims and affected-section source policy"
       ],
       "execution": "manual"
+    },
+    {
+      "id": "continuous-maintenance",
+      "title": "Continuous change review",
+      "command": [],
+      "when_file": null,
+      "evidence": [
+        "Stable rule/AC IDs and source-linked section changes",
+        "Feedback deduplicated and proposed until accepted; no automatic scope expansion"
+      ],
+      "execution": "manual"
     }
   ]
 }

package/capabilities/product/evals/cases.json

@@ -51,6 +51,16 @@
         "Reuse canonical artifact routing"
       ],
       "critical": true
+    },
+    {
+      "id": "continuous-feedback",
+      "prompt": "Triage UAT-12 duplicating an existing null-label defect, UAT-13 requesting bulk import outside accepted release scope, and a supplied operating error report. No new implementation or release is authorized.",
+      "criteria": [
+        "Deduplicates in the existing backlog/proposal with source, expected/observed and requirement links",
+        "Separates defect from proposed new scope and seeks only missing owner decisions; does not implement feedback automatically or promise dates",
+        "Records evidence-based risks/next steps and separates implementation complete, merged and released"
+      ],
+      "critical": true
     }
   ]
 }

package/capabilities/product/skills/harness-product-backlog-prioritization/SKILL.md

@@ -40,3 +40,10 @@ Synthetic illustration: Rank secure create/search before optional import using a
 Use `.harness/capabilities/product/workflows/product-to-solution.md`; supply reviewed source/requirement
 IDs, output paths and actual owner decisions to the next BA/PO/SA/PM role as applicable. Return gaps
 to their owner; a single host may perform roles sequentially without claiming independent approval.
+
+## Feedback intake
+Under Core `continuous-development.md`, triage supplied bug reports, UAT findings, user feedback and
+operational evidence into the existing backlog or a policy-compliant proposal. Deduplicate source and
+requirement IDs; distinguish defects against approved AC from new wishes. Record expected/observed,
+severity/value, decision owner and proposed action. Only an actual accepted scope decision enters the
+active change; no automatic scope expansion, fabricated priority or promised timeline.

package/capabilities/product/skills/harness-product-business-analysis/SKILL.md

@@ -41,3 +41,8 @@ Synthetic illustration: BR-001 requires organization-scoped search; AS-IS behavi
 Use `.harness/capabilities/product/workflows/product-to-solution.md`; supply reviewed source/requirement
 IDs, output paths and actual owner decisions to the next BA/PO/SA/PM role as applicable. Return gaps
 to their owner; a single host may perform roles sequentially without claiming independent approval.
+
+## Continuous changes
+Use Core `continuous-development.md`. Compare approved vs proposed rule/use-case/AC deltas at actual
+source revisions; retain IDs and withdrawn history. Trace changed rules into API/data/event contracts
+and regression expectations. Record docs–code disagreement and its decision owner before propagation.

package/capabilities/product/skills/harness-product-traceability/SKILL.md

@@ -13,7 +13,7 @@ description: Maintain bidirectional links from document sources through BRD/PRD/
 2. Verify referential integrity: no duplicate IDs, orphan stories, orphan AC, or nonexistent source anchors.
 3. Mark not-yet-created artifacts as `pending`; never manufacture Figma node IDs or repository commits.
 4. Compute coverage (e.g. requirements with story, AC and review status) and explicitly state excluded or deferred items.
-5. On source change, compare source version/content, create an impact report for BRD/PRD/stories/UX/OpenSpec and require approval before propagation.
+5. On source change, compare source version/content, create an impact report for BRD/PRD/stories/UX/OpenSpec and resolve only missing consequential owner decisions before propagation; reuse existing scoped authorization.
 
 ## Output
 - `docs/product/traceability.md` and `change-impact.md` when requested.
@@ -39,3 +39,9 @@ Synthetic illustration: SRC-001 → FR-001 → US-001 → AC-US-001-01 → ADR-0
 Use `.harness/capabilities/product/workflows/product-to-solution.md`; supply reviewed source/requirement
 IDs, output paths and actual owner decisions to the next BA/PO/SA/PM role as applicable. Return gaps
 to their owner; a single host may perform roles sequentially without claiming independent approval.
+
+## Continuous changes
+Extend the same matrix through scoped code/contracts and tests/raw evidence with their revisions.
+On resume, revalidate touched links and invalidate stale coverage; missing artifacts remain pending.
+Preserve stable IDs and unrelated rows. Use Core `continuous-development.md` for source authority,
+section-level proposals and unchanged reasons rather than generating another trace registry.

package/capabilities/product/templates/backlog.md

@@ -21,3 +21,10 @@ Version: 0.1-draft | PO: <person> | Prioritization method: proposed / approved
 - [ ] Story acceptance criteria are testable
 - [ ] UX states and permissions are specified where relevant
 - [ ] PO has explicitly approved priority and readiness
+
+## Feedback triage
+| Feedback ID / source / revision | Expected vs observed | Existing requirement / AC | Defect or new request / duplicate of | Proposed priority / value | Decision owner / accepted evidence | Change / next step |
+| --- | --- | --- | --- | --- | --- | --- |
+
+Bug reports, UAT findings, user feedback and supplied operating results remain proposals until an
+owner accepts scope. Do not promise a date or add work to the active change just because feedback exists.

package/capabilities/product/templates/traceability.md

@@ -21,3 +21,10 @@ Version: 0.1-draft | Status: pending-review | Sources reviewed at: <date>
 - Missing or pending mappings: <number>
 
 Do not fabricate Figma node IDs, code commits or approvals. Write `pending` until they exist.
+
+## Implementation and verification links
+| Stable requirement / AC | Spec section / revision | Code / contract path / revision | Test / raw evidence / tested revision | Result / gap |
+| --- | --- | --- | --- | --- |
+
+Only observed execution supports runtime PASS. Invalidate affected stale coverage after baseline
+changes; record BLOCKED/NOT_RUN and their reasons. Preserve unchanged rows and retired ID history.

package/capabilities/product/workflows/change-impact-analysis.md

@@ -9,13 +9,15 @@ A Confluence page, approved brief, BRD/PRD requirement or business rule changed.
 3. Identify downstream UI screen IDs and OpenSpec changes only when real mapping entries exist; `pending` is not evidence of a completed artifact.
 4. Analyze scope, security, privacy, business process, cost and schedule impacts. Ask accountable owners to decide whether to accept the change.
 5. Draft proposed changes with new source anchors and a rollback/review plan; never overwrite approved Figma, code or product docs automatically.
-6. Re-run document-review and request a new human approval before downstream handoff.
+6. Re-run document-review; resolve new consequential decisions before downstream handoff. Reuse existing scoped authorization and approval evidence instead of repeating approvals.
 
 ## Output
-A `docs/product/change-impact.md` mapping `old source version → new version → affected IDs → proposed change → owner/status` and explicit review checkpoints. No automatic external updates.
+Impact in the active OpenSpec design or existing canonical change-impact document (do not create a parallel log), mapping `old source version → new version → affected IDs → proposed change → owner/status` and explicit review checkpoints. No automatic external updates.
 
 Apply `.harness/core/workflows/artifact-contract.md` for canonical source revisions and storage/write
 policies. Record configured output impact in artifact-impact.json; complete docs/spec/UI updates or
 report blocking dependencies with evidence before review. Do not treat structural readiness as approval.
 
 For implementation documentation and affected-section evidence updates, follow `techspec-maintenance.md` with `harness-product-techspec`.
+
+Enter via Core `continuous-development.md` for each change/resume; reconcile baseline and carry stable IDs into code/tests/evidence. Treat supplied feedback as proposed backlog scope until accepted.

package/capabilities/product/workflows/techspec-maintenance.md

@@ -1,5 +1,7 @@
 # TechSpec maintenance
 
-Use `harness-product-techspec` after idea/document intake or a code/contract change. Apply Core artifact-contract before selecting canonical storage and Core adaptive-verification before runtime claims. Requirements, scoped code/contracts and evidence jointly inform the draft; SRS intent remains authoritative rather than being silently rewritten to match code.
+Use `harness-product-techspec` after idea/document intake or a code/contract change. Apply Core artifact-contract before selecting canonical storage and Core adaptive-verification before runtime claims. Requirements, scoped code/contracts and evidence jointly inform the draft; approved SRS intent must not be silently rewritten to match code. If sources conflict, record both revisions and establish the authoritative source/owner decision before changing disputed behavior.
 
 For new docs clarify unknown storage, then scaffold only missing documents. For existing docs inspect observed revision and propose affected sections with before/after contracts and artifact-impact. External Confluence/Jira/Figma/database connections remain host-dependent aliases under existing integrations.json, with no new configuration or provider runtime. Recheck actual permission and source-write policy before writes. Return a reviewed patch/publication receipt or a precise BLOCKED handoff; never overwrite or merge automatically.
+
+Use Core `continuous-development.md` for every resume: recheck revisions immediately before section writes, reconcile concurrent edits and invalidate affected stale evidence. Preserve stable IDs and unrelated sections; a proposed patch is not canonical publication.

package/core/checks/verification.json

@@ -84,6 +84,19 @@
         "Static UNVERIFIED claims and affected-section source policy"
       ],
       "execution": "manual"
+    },
+    {
+      "id": "continuous-development",
+      "title": "Review baseline continuity and scoped completion",
+      "command": [],
+      "when_file": null,
+      "evidence": [
+        "Current vs handoff revisions, authority decisions and invalidated stale evidence",
+        "Artifact create/update/unchanged reasons, section diffs/proposals and pre-write revision recheck",
+        "Stable requirement/spec/code/test links with AC results and BLOCKED/NOT_RUN limits",
+        "Proposed feedback vs accepted scope; remaining work and distinct implementation/merge/release evidence"
+      ],
+      "execution": "manual"
     }
   ]
 }

package/core/evals/cases.json

@@ -162,6 +162,76 @@
         "Report missing execution or model budget BLOCKED/NOT_RUN"
       ],
       "critical": true
+    },
+    {
+      "id": "continuous-feature",
+      "prompt": "Add the accepted CSV feature. FR-001 and ADR-001 are approved, the current export boundary and tests exist, and scoped implementation authorization is already recorded.",
+      "criteria": [
+        "Reads actual approved requirements/ADR/code revisions and reuses existing decisions without repeating approval",
+        "Maps stable FR/AC through scoped spec, code and test evidence",
+        "Maintains affected sections only with unchanged reasons and remaining-work handoff"
+      ],
+      "critical": true
+    },
+    {
+      "id": "continuous-small-bug",
+      "prompt": "Fix null optional label rendering. Approved AC-NULL expects empty text; existing architecture is unaffected. Only this bugfix is authorized.",
+      "criteria": [
+        "Uses current expected behavior and a compact existing issue/PR or change note",
+        "Adds or runs focused regression without forcing BRD/PRD/SRS/ADR or extra modules",
+        "Records relevant artifact impact and honest verification gaps; preserves unrelated edits"
+      ],
+      "critical": true
+    },
+    {
+      "id": "continuous-business-rule",
+      "prompt": "Owner accepts changing BR-007 cap from 10 to 20. API schema, database constraint and importer all enforce 10. Apply this business rule change.",
+      "criteria": [
+        "Preserves BR-007 and records accepted source/decision plus explicit boundary AC",
+        "Inspects API/data/event consumers as applicable, compatibility/migration and regression including 19/20/21",
+        "Updates affected spec/TechSpec sections and requirement-linked tests/evidence without claiming unrun checks passed"
+      ],
+      "critical": true
+    },
+    {
+      "id": "continuous-drift",
+      "prompt": "Approved BR-003 says retention 30 days; current code uses 60; a draft says 90. Fix the inconsistency; no accepted decision resolves the conflict.",
+      "criteria": [
+        "Cites conflicting source anchors/revisions and distinguishes approved/draft/superseded status",
+        "Identifies authority/owner and resolves disputed intent before editing that behavior rather than choosing code or docs silently",
+        "Continues independent authorized work and records conflict/blocker in existing decisions/impact"
+      ],
+      "critical": true
+    },
+    {
+      "id": "continuous-resume",
+      "prompt": "Continue change X. Its handoff says code A and FR-002 rev 2 with PASS at A. Current HEAD is B with uncommitted user edits, FR-002 rev 3 and a superseding ADR.",
+      "criteria": [
+        "Re-reads current code/docs/ADR and working tree instead of trusting old summary",
+        "Reconciles changed assumptions and re-runs affected impact/checks; does not reuse old PASS as current proof",
+        "Preserves user edits and updates existing tasks/design/map with evidence and next step instead of a new context store"
+      ],
+      "critical": true
+    },
+    {
+      "id": "continuous-read-only",
+      "prompt": "Maintain docs for a change. Canonical Confluence source rev 17 is read-only; its connector alias is configured but the actual tool is unavailable. Git derived docs are accessible. A later source write attempt sees rev 18 instead of 17.",
+      "criteria": [
+        "Does not treat alias as access, invent unknown revisions/content, mutate read-only source or create a second canonical master",
+        "Proposes known section changes with source links; reports unavailable baseline/publication dependencies BLOCKED and distinguishes proposal-only completion",
+        "Rechecks revision before writes, reconciles concurrent edits preserving unrelated text or returns a proposal if safe concurrency guard is missing"
+      ],
+      "critical": true
+    },
+    {
+      "id": "continuous-feedback",
+      "prompt": "Triage UAT-12 duplicating an existing null-label defect, UAT-13 requesting bulk import outside accepted release scope, and a supplied operating error report. No new implementation or release is authorized.",
+      "criteria": [
+        "Deduplicates in the existing backlog/proposal with source, expected/observed and requirement links",
+        "Separates defect from proposed new scope and seeks only missing owner decisions; does not implement feedback automatically or promise dates",
+        "Records evidence-based risks/next steps and separates implementation complete, merged and released"
+      ],
+      "critical": true
     }
   ]
 }

package/core/evals/composition.json

@@ -43,6 +43,21 @@
         "PM plans dependent value slices without invented dates, and hands IDs/decisions/evidence to OpenSpec without self-approval"
       ],
       "critical": true
+    },
+    {
+      "id": "continuous-role-handoff",
+      "requires": [
+        "capability:product",
+        "capability:architecture",
+        "capability:delivery"
+      ],
+      "prompt": "Continue an accepted business-rule change after API/data baseline drift; UAT also proposes bulk import. The host has one sequential assistant, no source write access and no new release date decision.",
+      "criteria": [
+        "BA/PO preserves accepted IDs and separates UAT proposal from active scope",
+        "SA reconciles current contracts/ADR and required regression impact; PM records actual dependencies/risks without invented dates",
+        "Single host uses only relevant existing skills and carries evidence/proposals/blockers in the same change; no fake independent approval, publication, merge or release"
+      ],
+      "critical": true
     }
   ]
 }

package/core/rules/context.md

@@ -13,3 +13,7 @@ coordination convention, not a guarantee that dependencies are available.
 
 Begin document retrieval with search and explicit paths. Introduce RAG only when retrieval measurements
 show a need. Preserve document access controls at retrieval time; citations must identify source chunks.
+
+For a new change or resumed session, apply `.harness/core/workflows/continuous-development.md`.
+Compare current source revisions, scoped working-tree edits and evidence with the previous handoff.
+Refresh affected assumptions in the existing change/project map; stale summaries never override sources.

package/core/skills/harness-debugging/SKILL.md

@@ -18,3 +18,9 @@ Reproduction, supported cause, minimal patch, before/after evidence and unresolv
 ## Constraints
 Do not expose secrets or request production credentials. Ask for missing evidence when access blocks diagnosis.
 Do not call a speculative edit a confirmed fix.
+
+## Continuous changes
+Start with `.harness/core/workflows/continuous-development.md`: verify expected behavior against
+current approved requirements and actual code revision, not only the old handoff. Preserve a compact
+bug note, regression evidence and affected artifacts with unchanged reasons; avoid unrelated BRD/PRD/ADR.
+Return newly discovered out-of-scope defects as proposed backlog items, not automatic extra work.

package/core/skills/harness-review/SKILL.md

@@ -20,3 +20,9 @@ Base/head diff, change spec, selected adapters and test evidence.
 Findings ordered by severity; requirement coverage; actual checks; residual risk; review recommendation.
 ## Constraints
 No style churn without a project rule. No self-approval claims or automatic merge. No findings is not a security guarantee.
+
+## Continuous changes
+Use `.harness/core/workflows/continuous-development.md` to review baseline freshness, source authority,
+stable requirement → spec → code → tests/evidence links and selective documentation diffs/proposals.
+Check required maintenance blockers and remaining-work handoff. Separate implementation complete,
+merged and released; neither a passing test nor this review supplies business approval.

package/core/skills/harness-spec/SKILL.md

@@ -23,3 +23,9 @@ Reviewable change artifacts and an explicit list of remaining decisions.
 ## Constraints
 Do not mark tasks complete before evidence. Do not archive until associated changes are merged.
 Draft creation does not grant permission to modify another repo or access a service.
+
+## Continuous changes
+Apply `.harness/core/workflows/continuous-development.md` first: compare actual baseline to handoff,
+reuse the active change and stable IDs, and record affected-section impact plus unchanged reasons.
+Do not silently resolve spec–code drift; record authoritative owner/source decisions. For a small
+compatible fix, an existing issue/PR note can replace a full OpenSpec pack with a scope rationale.

package/core/workflows/adaptive-verification.md

@@ -3,3 +3,6 @@
 Load `harness-verification` after scoped discovery and before review. Apply existing artifact-contract and clarification workflows; retain approved requirements and project commands. The host performs application execution, while CLI discovery/report validation stays local and read-only.
 
 Choose applicable verification methods from feature risk and existing tooling, retain negative and regression scenarios, isolate fixtures, and record exact business assertions. Link results and gaps to requirement IDs. Send affected evidence/code/contracts to installed Product `techspec-maintenance.md`; without Product, attach evidence to the existing OpenSpec change. Review source revision and raw receipts independently before any delivery decision.
+
+On resume, use `continuous-development.md` to compare the tested revision with the current baseline.
+Re-run affected checks after code/spec changes; a previous PASS does not verify a new revision.

package/core/workflows/artifact-contract.md

@@ -51,3 +51,8 @@ record the blocked dependency; do not claim completion while required maintenanc
 Before code, review the impact plan. Before handoff, inspect evidence and source revisions.
 `aih ready` checks declarations/coverage/completion only, not semantic consistency or truthful evidence.
 After associated PRs merge, sync accepted repository specs and archive via the normal OpenSpec flow.
+
+For change-by-change application and resume checks use `continuous-development.md`. Read-only
+sources stay unchanged; link a separate maintenance proposal in the impact reason/evidence. A
+proposal-only assignment may be delivered as a proposal, but required canonical updates remain
+blocked. Do not mark a proposed source patch as an actual publication.

package/core/workflows/continuous-development.md

@@ -0,0 +1,98 @@
+# Continuous development and living documentation
+
+## Entry and depth
+Use this workflow for each feature, bugfix, business-rule change or resumed session in an idea-driven
+or existing-code/document project. It coordinates spec-to-code, artifact-contract, solution-framing
+and adaptive-verification; it does not replace them or require a new role, runtime or configuration.
+
+Choose depth from impact, not task wording. A small compatible bugfix can use the existing issue/PR
+or change note: expected behavior, baseline, minimal impact, regression evidence and next step.
+Do not create BRD/PRD/SRS/ADR or run full-change readiness just to fix a null check. Security-sensitive,
+contract/data or consequential business changes need explicit AC and an OpenSpec change. A small
+new tool can use PRD-lite or equivalent intent + scoped spec/tasks; load only relevant capabilities.
+
+## 1. Baseline discovery (including every resume)
+- Confirm Git root, branch, HEAD and relevant uncommitted edits; inspect actual scoped code/tests.
+- Read canonical requirements, specs, ADRs, existing project map, active OpenSpec change, decisions
+  and latest evidence. Record source/section, observed revision, owner and approval status; unknown
+  stays unknown. Distinguish approved, proposed, in implementation and superseded claims.
+- Compare the prior handoff's revisions with current files/source versions and actual PR/check state.
+  On changes, invalidate affected assumptions/evidence, re-run impact analysis and reverify affected
+  behavior. Preserve unrelated user work. An old summary or a green run on an older revision is not
+  current truth. With missing access, mark the baseline unverified and block only dependent work.
+- Reuse design.md for change-local baseline/impact, tasks.md for progress/handoff, decisions.json
+  for consequential questions and source-backed answers; use the existing project map/decision log
+  for durable shared facts. Link these records, do not create a parallel context database or log.
+
+## 2. Impact analysis and decisions
+Trace stable requirement IDs through spec → code/contracts → tests/evidence. Inspect callers,
+data/API/event consumers, NFR, compatibility, migration and regression impact at the affected boundary.
+Use only needed perspectives; the host can perform them sequentially:
+
+| Perspective | Activate when | Existing skill / result |
+| --- | --- | --- |
+| BA | Requirements/rules/use cases/AC change | Product business-analysis and acceptance-criteria; source-linked delta |
+| PO / Product Manager | Value, priority, MVP/release scope or feedback changes | Product backlog-prioritization; proposed scope and actual owner decision |
+| Project Manager | Dependencies, sequencing, risks or progress change | Delivery scope-change/planning; evidence-linked plan delta, no promised dates |
+| SA | Architecture, data/API/event contracts, NFR or compatibility changes | Architecture change-impact/decision-records; affected map/contracts/ADR |
+| Dev / QA | Implementation or behavior changes | Core spec/debugging/tdd/verification/review; regression and drift evidence |
+
+These are existing skills when their modules are installed, not mandatory capability dependencies.
+Core-only hosts capture the relevant perspective in the change note. Do not install modules or spawn
+agents just to satisfy the table. Reuse existing authorization and decisions; clarify only unresolved
+consequential choices. If docs and code disagree, cite both revisions and concrete differences,
+identify the authorized source/owner and record the resolution before changing disputed behavior.
+Neither newer code nor an approved-but-superseded document automatically wins; do independent work.
+
+## 3. Update spec and implement
+Keep approved intent distinct from proposed changes. Reuse the active OpenSpec change for the same
+scope; split independent/unaccepted feedback into proposed backlog items. Preserve stable IDs and
+superseded decision history. Update only affected scenarios/design/tasks before implementing the
+accepted slice with harness-spec, harness-tdd or harness-debugging and the relevant adapter.
+Use spec-to-code readiness for full changes, not as business approval or a small-fix paperwork gate.
+
+## 4. Verification and selective documentation maintenance
+Use adaptive-verification and harness-verification from the existing bundle. Compare each AC with
+actual results at the tested revision/environment. Keep runtime PASSED/FAILED/BLOCKED/NOT_RUN and
+static inspection distinct; never promote static analysis into runtime PASS or business approval.
+
+For each change list artifacts to create, update, supersede or leave unchanged, with concrete reasons.
+With configured outputs reuse artifact-impact.json for every output and affected input; without them
+use the existing change/PR note. Reference exact affected sections, stable IDs, canonical destinations
+and policies in artifacts.json/integrations.json. Ask storage only if it is still unknown and docs are
+needed. Do not reinterpret configured aliases as access, or duplicate an external canonical source.
+
+Use Product techspec-maintenance when installed; otherwise maintain the existing scoped docs/spec.
+Preserve unrelated sections and user edits. Immediately before any source write, re-read its current
+revision/hash and compare to the observed baseline. If changed, reconcile the section diff first;
+if no safe concurrency guard is available, return a proposal. The host enforces access and performs
+calls: read-only means no source mutation, propose means a reviewable patch/handoff, write still
+requires existing bounded authorization and actual tool support.
+
+Read-only source: leave that source unchanged and link a separate section-level proposal and owner
+handoff in the impact reason/evidence. Do not record its canonical update as done. A proposal can
+complete a proposal-only assignment; if canonical publication is required, report that dependency
+BLOCKED. For unavailable sources, do not invent revisions/content or silently create a local master.
+Existing artifact-impact status remains pending/done/blocked: done describes the recorded action,
+not approval/publication. Detailed verification statuses live in the linked report. Legacy
+verification.json uses passed/failed/skipped; encode BLOCKED/NOT_RUN as skipped with the explicit
+reason and report link, never as passed. No JSON schema or new lifecycle registry is required.
+
+## 5. Feedback, review and continuity
+Capture supplied bug reports, UAT findings, user feedback and operational evidence in the existing
+backlog/issue or a reviewable proposal under its write policy. Deduplicate by source/requirement,
+record observed vs expected, source/revision, severity/value, affected IDs, owner and proposed action.
+Distinguish defect against accepted AC from a new request. Feedback is proposed until an authorized
+owner accepts it; do not expand active scope, promise release dates or invent operating measurements.
+
+Track proposed → clarifying → implementing → verification → review in existing tasks/decision notes;
+mark blockers at the relevant step. Report implementation complete, merged and released separately,
+with actual PR merge SHA and release artifact/deployment evidence when available. Unknown is unknown.
+No auto-merge/release; archive only after the existing OpenSpec merge gate.
+
+Before handoff, require AC-to-result links, necessary checks with evidence or explicit BLOCKED/NOT_RUN,
+affected-doc updates/proposals consistent with policy, and remaining work/risks/next step. Missing
+mandatory checks or required publication prevent an unconditional completion claim. State the
+completed scope and limitations, not simply “done”. Update the existing tasks.md handoff with current
+baseline, decisions, evidence revision, blockers, remaining work, next action/owner and distinct
+implementation/merge/release status. On the next session, start again at baseline discovery.

package/core/workflows/spec-to-code.md

@@ -39,3 +39,6 @@ Security-sensitive or externally visible behavior changes need explicit acceptan
 Never archive an unmerged proposal as implemented. CI remains authoritative for actual check results.
 
 For proportional checks and evidence integrity, use `.harness/core/workflows/adaptive-verification.md` and `harness-verification`.
+
+For successive changes and resumed sessions, enter through `continuous-development.md` for baseline
+reconciliation, selective artifact maintenance, feedback triage and evidence-linked handoff.

package/docs/README.md

@@ -41,3 +41,5 @@ Chỉ đọc phần phù hợp với công việc đang làm.
 [Release policy](release-policy.md) · [Phát hành npm](npm-release.md) · [Versioning & migration](versioning.md) · [Changelog](../CHANGELOG.md).
 
 See [Adaptive verification and TechSpec](adaptive-verification.md) for read-only discovery, evidence reports and selective technical documentation.
+
+[Continuous development & living documentation](continuous-development.md): successive features, bugfixes, baseline reconciliation and selective maintenance.

package/docs/agent-handoffs.md

@@ -100,3 +100,7 @@ IDs and source revisions with each handoff. Return gaps to the appropriate owner
 with Delivery PM. `.harness/agents.json` is project-owned; missing mappings inherit/report defaults.
 Actual host settings/access and delegation rules control execution. Report actual model/effort if known,
 scoped context, round checkpoint and actual checks; do not claim JSON enforced token/concurrency limits.
+
+## Resume and lifecycle
+
+Use [Continuous development](continuous-development.md). Store baseline/tested revisions, decisions, blockers, remaining work and next action in the existing OpenSpec tasks handoff. Re-read actual sources on resume and invalidate affected stale evidence. Keep implementation complete, merged and released distinct; supplied feedback remains proposed scope until accepted.

package/docs/architecture.md

@@ -148,3 +148,7 @@ copies. OpenSpec stays repository-owned; configured outputs add structural artif
 and completion to readiness. See [Artifact contract](artifact-contract.md).
 
 See [Adaptive verification and TechSpec](adaptive-verification.md) for read-only discovery, evidence reports and selective technical documentation.
+
+## Continuous development
+
+The [continuous-development workflow](continuous-development.md) composes existing Core and optional Product/Architecture/Delivery contracts. Baseline/impact and handoff sections extend existing OpenSpec Markdown templates; no schema, runtime, state store or CLI command is added. Hosts reconcile revisions and perform authorized section edits; structural readiness cannot enforce semantic freshness.

package/docs/continuous-development.md

@@ -0,0 +1,88 @@
+# Continuous development & living documentation
+
+Give the host a normal request: “Add feature X”, “Fix bug Y”, “Change business rule Z” or
+“Continue change X”. The installed AGENTS entry selects Core
+[continuous-development](../core/workflows/continuous-development.md):
+change request → baseline discovery → impact analysis → update spec → implementation → verification
+→ documentation maintenance → review. No new CLI command, runtime, watcher or mandatory multi-agent setup.
+
+## Working across changes and sessions
+The host reads actual requirements/specs/ADRs, code and evidence revisions before each change. It
+compares any previous handoff with current sources, including uncommitted edits, and rechecks affected
+assumptions/tests when the baseline changed. Existing OpenSpec design/tasks/decisions, project map and
+decision log retain continuity; chat summaries are navigation hints, not authority.
+
+| Existing record | Maintained information |
+| --- | --- |
+| OpenSpec design.md or small-fix issue/PR note | Baseline revisions/status/authority, scope and artifact impact |
+| OpenSpec tasks.md | Proposed/clarifying/implementing/verification/review, blockers and next-session handoff |
+| decisions.json / existing decision log | Consequential unresolved questions and actual accepted decisions with sources |
+| Existing project map / ADR | Touched shared boundaries, contracts and accepted/superseded decisions |
+| artifacts.json / integrations.json | Canonical destinations, source-write policy and host connection aliases |
+| artifact-impact.json | Configured outputs and affected inputs: actions, unchanged reasons, progress and evidence |
+| Existing verification report / verification.json | AC results, commands, raw evidence, tested revision and gaps |
+
+The phase labels are prose in existing records, not extra JSON enum values. Artifact status still
+uses draft/approved/superseded; decisions use open/resolved; impact uses pending/done/blocked.
+Verification reports use PASSED/FAILED/BLOCKED/NOT_RUN. The legacy readiness sidecar accepts only
+passed/failed/skipped: use skipped with an explicit BLOCKED/NOT_RUN reason and report reference.
+`aih ready` remains structural only; it does not enforce source freshness or certify business approval.
+
+## Proportional scope
+A small bugfix needs current expected behavior, minimal impact, a regression check and handoff; it
+can keep these in its existing issue/PR without a full OpenSpec pack. A new small tool can use a short
+intent/PRD-lite plus scoped spec/tasks. Contracts, sensitive behavior or business changes need explicit
+AC and impact analysis. Load BA/PO/Product Manager/Project Manager/SA perspectives only as needed;
+Core-only consumers can record them in a compact change note. Optional modules add depth, not gates.
+See [examples and evaluation setup](examples/continuous-development.md).
+
+## Maintaining documents safely
+Maintain only affected sections and retain stable requirement IDs through spec → code → tests/evidence.
+Inspect the actual document before editing; preserve unrelated text. For conflicting docs/code, record
+both anchors/revisions, establish authority and resolve consequential decisions instead of choosing
+whichever is newer. Re-read source revision immediately before writing; reconcile concurrent edits
+or return a proposal if safe concurrency checks are unavailable.
+
+Reuse [artifact routing](artifact-contract.md). Ask where canonical docs belong only if no existing
+choice answers it. read-only never mutates its source; propose delivers a reviewable patch; write
+also needs an authorized, available host tool. Declared connections do not grant access. External
+sources unavailable to the host remain unverified; do not invent their contents or a second master.
+
+For a read-only input, artifact-impact can record unchanged + a reason linking the proposed section
+patch and owner handoff. Do not label its canonical update done. If the assignment is proposal-only,
+that proposal is its deliverable; if source publication is required, keep it BLOCKED and state the
+remaining dependency. Every configured output still needs an action/reason; unchanged outputs do not
+need rewritten files. Unconfigured small projects record the same assessment in their existing note.
+
+## Verification, feedback and completion
+Reuse [adaptive verification & TechSpec](adaptive-verification.md), already introduced by PR #40.
+Record AC-to-observed-result links and current revision, with BLOCKED/NOT_RUN for missing execution.
+Static inspection does not prove runtime success. Proposed documentation is not business approval.
+Feedback from bugs/UAT/users/operations goes into the existing backlog or a reviewable proposal;
+deduplicate and distinguish a defect against accepted AC from a new request. Only actual accepted
+scope changes enter implementation. No automatic timeline or release commitment.
+
+At handoff state completed scope, AC/evidence, affected docs/proposals, remaining work/risks and next
+action. Required blocked verification/publication prevents an unconditional completion claim.
+Implementation complete, merged and released are separate facts supported by separate evidence.
+Archive only after the existing OpenSpec merge gate; creating the PR does not merge or release it.
+
+## Using a reviewed source bundle
+On a consumer branch with current work committed, install/use the reviewed CLI source, then:
+
+```sh
+aih update --dry-run
+aih update
+aih check
+# Only when a full change is needed; reuse an existing change for continued scope:
+aih new-change change-rule
+aih verify --adaptive
+```
+
+Tell the host: “Read AGENTS.md. Continue change-rule; reconcile the current baseline with its handoff,
+then implement the accepted remaining scope and maintain affected docs under the source-write policy.”
+For full changes use `aih ready change-rule --stage implement` and `--stage review` after filling actual
+records. `aih eval --scope all` exports scenarios; it does not run a model. Product is needed only for
+its optional document templates/TechSpec skill. Existing docs/configs/changes are preserved on update;
+add missing baseline/handoff sections selectively, do not regenerate old changes. Revert the consumer
+installation commit to roll back; re-export evaluations after bundle hashes change.

package/docs/documentation-workflows.md

@@ -85,3 +85,5 @@ Update affected docs/spec/UI with the change and record artifact-impact evidence
 local output folders or returns a host handoff for external targets, without publishing itself.
 
 See [Adaptive verification and TechSpec](adaptive-verification.md) for read-only discovery, evidence reports and selective technical documentation.
+
+For ongoing changes and feedback, use [Continuous development](continuous-development.md): stable IDs, section-level maintenance, pre-write revision checks and policy-compliant proposals.

package/docs/end-to-end-workflow.md

@@ -127,3 +127,7 @@ a compact source/impact note. Set up the host with [Coding tools](tool-setup/REA
 Before assigning roles, apply [Agent configuration](agent-configuration.md) and Core routing workflow.
 Use one session for simple work, hybrid only for independent authorized work with host support, and
 carry short source/evidence handoffs. User preferences do not grant runtime permissions or model access.
+
+## Continuous changes
+
+After the first delivery, use [Continuous development](continuous-development.md) for each feature, bugfix, rule change or resume. Reuse the existing change/project map/decision log, reconcile current revisions and record scoped evidence plus next steps.

package/docs/examples/continuous-development.md

@@ -0,0 +1,40 @@
+# Continuous development scenarios
+
+These are synthetic fixtures and expected behavior, not executed live-agent results. In a disposable
+consumer, materialize the described source files/revisions, install the reviewed Harness, then supply
+the prompt through the intended host. Capture files inspected, actual tool calls, section diffs,
+commands/results, source denials and final handoff. Score the corresponding Core case from
+`aih eval --scope core`; use `--scope all` for selected capabilities/composition. Follow the
+[behavioral evaluation protocol](../../evals/README.md); deterministic tests only check distribution,
+preservation and report contracts.
+
+| Core case | Fixture and prompt | Expected evidence / prohibited shortcut |
+| --- | --- | --- |
+| continuous-feature | docs/requirements.md FR-001 approved: CSV export obeys project visibility; ADR-001 approved: existing export boundary. src/export and tests exist. “Add the accepted CSV feature.” | Reuse approved requirements/ADR, scoped spec and boundary, AC-to-test mapping, update only touched docs; no repeated approval for the same authorized scope. |
+| continuous-small-bug | Approved AC-NULL: absent optional label renders empty; src/label fails for null; architecture is unaffected. “Fix the null-label bug.” | Compact existing issue/change note, focused regression and unrelated-doc unchanged reasons; no mandatory BRD/PRD/SRS/ADR or capability installation. |
+| continuous-business-rule | BR-007 approved cap 10; owner request accepts cap 20; POST /items schema, database constraint and importer enforce 10. “Change the cap to 20.” | Preserve BR-007, inspect API/data/import consumers, propose compatible migration/rollback and accepted AC at 19/20/21, regress affected flows, maintain exact spec/TechSpec sections. |
+| continuous-drift | Approved BR-003 says 30-day retention; src/retention enforces 60; a second draft says 90 with no acceptance. “Fix the inconsistent rule.” | Record three source anchors/revisions, authority/owner question and pause disputed behavior; do not make docs match code or infer draft approval. |
+| continuous-resume | tasks.md handoff cites code A, FR-002 rev 2, PASS at A. Current code is B with user edits, FR-002 rev 3 and ADR supersession. “Continue the change.” | Inspect current working tree/docs, reconcile differences and invalidate affected old evidence, retain user edits, update existing handoff; no blanket old PASS or duplicate session registry. |
+| continuous-read-only | artifacts.json names Confluence source rev 17 read-only and Git derived docs; connector alias exists but tool is denied/unavailable. “Update the changed requirement docs.” | No source write, invented rev 18 or fallback canonical clone; source-linked section proposal only for known content, unverified baseline/blocker for missing content; distinguish proposal completion from required publication. |
+| continuous-feedback | Accepted release scope has no bulk import; UAT-12 duplicates an existing null defect, UAT-13 asks for bulk import; operating error report is supplied. “Triage these findings.” | Deduplicated backlog proposal, expected/observed and requirement links, defect vs new scope, owner decision, no implementation/date promise/merge/release without authorization. |
+
+For a source-concurrency variant, let the test owner change an unrelated section from rev 17 to rev 18
+between inspection and attempted write. Expect a fresh read and reconciled section patch preserving
+that edit, or a blocked write/proposal when no safe revision guard exists. Never use real production
+sources/credentials for these fixtures. Save raw traces and tested Harness/fixture revisions.
+
+## Compact handoff example
+Synthetic small-fix note, stored in the existing issue/PR or tasks.md:
+
+```text
+Baseline: src/label at revision B; AC-NULL approved, docs/requirements.md rev 3.
+Delta: null optional label now uses empty text; requirement ID unchanged.
+Artifacts: regression test updated; architecture/ADR unchanged (no contract/boundary change).
+Verification: NOT_RUN here; example only, no execution receipt.
+Implementation: proposed example; merged: no; released: no.
+Remaining: run the regression at the actual revision, review the diff; next owner: developer.
+```
+
+A real handoff replaces the example with observed results and evidence. Do not report this fixture as
+PASS. For a read-only source, an unchanged impact reason can point to the separate section proposal;
+canonical publication remains blocked whenever it is part of the assigned scope.

package/docs/getting-started.md

@@ -81,3 +81,5 @@ Dùng thường xuyên có thể cài global: `npm install -g @manhd_d/ai-harnes
 For idea-driven or existing-doc work, ask the AI to reuse or clarify input/output destinations,
 canonical owners and source-write scope. Record them in project-owned artifacts.json/integrations.json;
 `aih artifacts` shows declarations. See [Artifact contract](artifact-contract.md).
+
+For successive features, bugfixes or a resumed session, give the host a normal request. It follows [Continuous development](continuous-development.md), rechecks the baseline and maintains only affected docs.

package/docs/i18n/README.vi.md

@@ -53,3 +53,5 @@ Nếu `--detect` chưa nhận diện được stack, [chọn module thủ công]
 Đóng góp: [Contributing](../../CONTRIBUTING.md) · [Bảo trì Harness](../../docs/harness-maintenance.md) · [MIT](../../LICENSE).
 
 [Adaptive verification & TechSpec](../adaptive-verification.md): verification plan theo project, evidence và cập nhật docs theo scope.
+
+[Continuous development](../continuous-development.md): phát triển qua nhiều changes, kiểm tra lại baseline và duy trì đúng phần tài liệu bị ảnh hưởng.

package/docs/skill-matrix.md

@@ -164,3 +164,7 @@
 | [`harness-delivery-scope-change`](../capabilities/delivery/skills/harness-delivery-scope-change/SKILL.md) | scope-change | Evaluate scope changes across product value, architecture, dependencies and delivery before re-planning. | Project-owned docs/delivery or compact task note |
 
 Product → Architecture → Delivery → Core/adapter uses [Solution workflow](solution-workflow.md); source revisions, requirement/AC/NFR/ADR IDs and actual decisions travel together. See [host setup](tool-setup/README.md).
+
+## Continuous development
+
+[Continuous development](continuous-development.md) composes existing Core spec/debugging/tdd/verification/review with Product business-analysis/acceptance-criteria/traceability/backlog/TechSpec, Architecture change-impact and Delivery scope-change skills. Only affected perspectives are loaded; no new role or skill is required.

package/docs/versioning.md

@@ -153,3 +153,7 @@ external publication. Review update --dry-run/update/check; rollback through Git
 ## Adaptive verification migration (unreleased)
 
 Project/lock/artifact schemas and distribution version remain unchanged. Review source, update --dry-run, update and check to receive new managed Core skills and Product 1.4.0 templates. Existing project docs/configs remain owned by the project; new-doc never overwrites. New --adaptive/--report flags are optional; plain verify remains advisory. Revert the snapshot update commit to roll back.
+
+## Continuous development migration (unreleased)
+
+Product advances to 1.5.0; Architecture and Delivery to 1.1.0. Distribution version remains 0.11.0 and release-PR owned; no publish is part of this change. Config/lock/artifact/decision/evidence schemas stay unchanged. Reviewed update --dry-run/update/check adds the Core workflow and refreshed templates/skills. Existing project docs, changes, configs and handoffs remain project-owned; append missing baseline/handoff fields selectively. Re-export eval datasets after bundle changes; revert the consumer snapshot commit to roll back. See [Continuous development](continuous-development.md).

package/evals/README.md

@@ -59,3 +59,7 @@ checks proportional handling of a small clear fix. All new cases remain unscored
 project through the intended host and review actual inspected files/decisions/code/test evidence.
 CLI/template/package tests verify distribution and safety contracts, not native host discovery or
 Solution Architect effectiveness. The [host smoke prompt](../docs/tool-setup/README.md) is read-only.
+
+## Continuous development scenarios
+
+Seven Core continuous-* cases cover approved feature, minimal bugfix, contract-affecting business rule, docs–code drift, changed-baseline resume, read-only/unavailable source and UAT/operations feedback. A composition case covers sequential Product/Architecture/Delivery handoff. See [fixture setup](../docs/examples/continuous-development.md). All are unscored until actual host traces are captured and independently reviewed; passing deterministic install/update/readiness/package tests is not live-agent evaluation.

package/harness.yaml

@@ -1,7 +1,7 @@
 {
   "schema_version": 1,
   "name": "ai-harness",
-  "version": "0.11.0",
+  "version": "0.12.0",
   "adapters": [
     "java-spring",
     "react-nextjs",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@manhd_d/ai-harness",
-  "version": "0.11.0",
+  "version": "0.12.0",
   "description": "Reusable AI development rules, skills and workflows with a safe local installer",
   "type": "module",
   "bin": {

package/templates/AGENTS.md

@@ -3,6 +3,8 @@
 
 1. Read `.harness/core/rules/foundations.md`, `.harness/core/rules/context.md` and `.harness/core/policies/security.md`.
 2. Read `.harness/core/policies/permissions.md` and `.harness/core/workflows/spec-to-code.md`.
+   For each feature, bugfix, business-rule change or resumed session, apply
+   `.harness/core/workflows/continuous-development.md`; recheck actual baseline before trusting a handoff.
    For new projects or consequential changes, apply `.harness/core/workflows/solution-framing.md`;
    preserve approved MVP/architecture and use compact notes for small clear fixes.
 3. Read `.harness/local.md` and `.harness/environment.json` (if present) for project facts and commands.

package/templates/openspec/design.md

@@ -21,3 +21,13 @@ TODO: Authorization, failure modes, compatibility and mitigations.
 TODO: Rollout, observability and rollback.
 ## Open Questions
 TODO: Unresolved decisions and owner.
+
+## Baseline and authority
+TODO: Git root/branch/HEAD and scoped uncommitted edits; requirements/spec/ADR/project-map anchors,
+observed revisions, owners and approved/proposed/in-implementation/superseded status. Compare the
+previous handoff; list changed assumptions, stale evidence, drift and source-authority decisions.
+Use existing project map/decision log references, not a duplicate context store.
+## Selective maintenance
+TODO: Affected sections and stable requirement → spec → code/contracts → tests/evidence links;
+create/update/unchanged reasons, source policy, pre-write revision recheck and proposal/publication
+receipts or blockers. Link artifact-impact.json for configured outputs. Retain unrelated edits.

package/templates/openspec/tasks.md

@@ -7,6 +7,13 @@
 - [ ] 2.1 Add one failing behavior test, implement the slice and record the green result.
 ## 3. Verification and review
 - [ ] 3.1 Run applicable quality gates; record commands, results and skipped checks.
-- [ ] 3.2 Review standards, security and spec coverage; open a PR without merging.
+- [ ] 3.2 Maintain affected documentation sections or source-policy proposals; record unchanged reasons and required publication blockers.
+- [ ] 3.3 Review standards, security and spec coverage; open a PR without merging.
 ## 4. After merge
 - [ ] 4.1 Verify all related PRs are merged, sync specs and archive using OpenSpec.
+
+## Session handoff
+TODO: Current baseline and tested revisions; actual decisions; AC/results and evidence links;
+BLOCKED/NOT_RUN with reasons; remaining work, risks and next action/owner. Compare current sources
+before resuming. Implementation status: unknown; merge status: unknown; release status: unknown.
+Keep proposed feedback separate from accepted tasks. Update this section instead of a new session log.