eybersjp · Oct 1, 2026 · Oct 1, 2026 · Oct 1, 2026 · Oct 1, 2026 · Oct 1, 2026
@@ -20,10 +20,10 @@ jobs:
 
     steps:
       - name: Check out repository
-        uses: actions/checkout@v4
+        uses: actions/checkout@v7
 
       - name: Set up Node.js
-        uses: actions/setup-node@v4
+        uses: actions/setup-node@v7
         with:
           node-version: 22
 

@@ -22,15 +22,15 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Check out repository
-        uses: actions/checkout@v4
+        uses: actions/checkout@v7
 
       - name: Configure Pages
-        uses: actions/configure-pages@v5
+        uses: actions/configure-pages@v6
         with:
           enablement: true
 
       - name: Upload site artifact
-        uses: actions/upload-pages-artifact@v3
+        uses: actions/upload-pages-artifact@v5
         with:
           path: website
 
@@ -43,4 +43,4 @@ jobs:
     steps:
       - name: Deploy to GitHub Pages
         id: deployment
-        uses: actions/deploy-pages@v4
+        uses: actions/deploy-pages@v5
@@ -14,8 +14,8 @@ jobs:
     timeout-minutes: 15
 
     steps:
-      - uses: actions/checkout@v4
-      - uses: actions/setup-node@v4
+      - uses: actions/checkout@v7
+      - uses: actions/setup-node@v7
         with:
           node-version: 22
       - run: npm run release:validate
@@ -25,7 +25,7 @@ jobs:
     runs-on: ubuntu-latest
 
     steps:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@v7
         with:
           fetch-depth: 0
 
@@ -40,8 +40,8 @@ jobs:
     environment: npm
 
     steps:
-      - uses: actions/checkout@v4
-      - uses: actions/setup-node@v4
+      - uses: actions/checkout@v7
+      - uses: actions/setup-node@v7
         with:
           node-version: 22
           registry-url: https://registry.npmjs.org

@@ -22,13 +22,13 @@ jobs:
 
     steps:
       - name: Check out main
-        uses: actions/checkout@v4
+        uses: actions/checkout@v7
         with:
           ref: main
           fetch-depth: 0
 
       - name: Set up Node.js
-        uses: actions/setup-node@v4
+        uses: actions/setup-node@v7
         with:
           node-version: 22
 
@@ -110,13 +110,13 @@ jobs:
 
     steps:
       - name: Check out release tag
-        uses: actions/checkout@v4
+        uses: actions/checkout@v7
         with:
           ref: ${{ needs.release.outputs.tag }}
           fetch-depth: 0
 
       - name: Set up Node.js for npm
-        uses: actions/setup-node@v4
+        uses: actions/setup-node@v7
         with:
           node-version: 22
           registry-url: https://registry.npmjs.org

@@ -6,6 +6,18 @@ The format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) and
 
 ## [Unreleased]
 
+### Added
+- **Development Modes**: Five project-owned development methodologies (Rapid, Balanced, Specification-Driven, Documentation-Driven, Maintenance & Evolution) with revisioned persistence, deterministic policy resolution, mode-aware artifact/planning behavior and immutable Development Contract mode snapshots.
+- **IDEA Authority Runtime**: Explicit requirement provenance, persisted one-question-at-a-time numbered interactions, exact interaction fingerprints, crash-safe discovery journaling, replay-protection receipts, Product Owner-bound Design Authority disposition and source-bound Idea Brief approval.
+
+### Changed
+- Development Contract schema advances to v1.2.0 for current mode-snapshot binding while retaining validation compatibility for v1.0/v1.1 contracts.
+- Suggestion promotion now requires explicit Product Owner decision authority instead of silently defaulting authority.
+- GitHub Actions use current major action versions identified by repository dependency automation, removing deprecated Node 20 action-runtime warnings.
+
+### Security
+- IDEA authority fails closed on stale interaction sources, fingerprint mismatch, replay, corrupted journal/receipt/workflow chains, implicit approval authority and direct Idea Brief tampering.
+
 ## [0.11.1] - 2026-09-30
 
 ### Added

@@ -137,7 +137,7 @@ The Authority Graph can block acceptance when requirements are unverified, crite
 
 ## What DKF provides today
 
-| Capability | Current v0.11.1 behavior |
+| Capability | Published v0.11.1 behavior |
 |---|---|
 | **Automated Guided Workflow** | `/dk-autopilot` coordinates the lifecycle and persists progress between sessions. |
 | **Numbered Decision Interface** | Deterministic bounded Product Owner choices and structured suggestion promotion. |
@@ -183,9 +183,14 @@ The long-term architecture focuses on:
 
 Read the full [DKF Strategic Direction](STRATEGY.md).
 
-### Active unreleased work
+### Post-v0.11.1 mainline additions
 
-Development Modes is being reconciled from its original pre-v0.11 branches onto the current v0.11.1 architecture. It remains **unreleased** until all five increments, independent verification, cross-mode compatibility checks, and Product Owner host acceptance are complete. Track the work in [Issue #50](https://github.com/eybersjp/development-kit/issues/50).
+The published release remains **v0.11.1**. Current `main` also contains two fully integrated, release-gated additions that are **not yet part of a published package release**:
+
+- **Development Modes** — Rapid, Balanced, Specification-Driven, Documentation-Driven, and Maintenance & Evolution; persisted methodology policy is revisioned and immutably bound into new Development Contracts without weakening mandatory DKF controls.
+- **IDEA Authority Hardening** — explicit requirement provenance, Product Owner-bound transitions, one persisted fingerprinted interaction at a time, crash-safe discovery journaling, replay-proof consumption receipts, Design Authority binding, and Idea Brief approval bound to exact discovery/design/artifact fingerprints.
+
+Both additions passed the repository's full Ubuntu and Windows release-validation matrix before merge. Their presence on `main` does not imply npm/GitHub release publication until the next versioned release is explicitly created.
 
 ---
 

@@ -37,18 +37,34 @@ The remaining roadmap is about making this reliability model **adaptive, portabl
 
 ---
 
-## Active unreleased work — Development Modes
+## Integrated post-v0.11.1 mainline work
 
-Development Modes is a current implementation stream, not a shipped v0.11.1 capability. The original Increment 001 and 002 branches predate v0.11.0/v0.11.1 and are being treated as historical implementation evidence while the feature is reconciled onto current `main`.
+The published baseline remains **v0.11.1**, while current `main` contains the following release-gated additions awaiting a future versioned release:
 
-Required completion scope:
-- reconcile and independently verify policy architecture and persisted mode configuration;
-- make lifecycle, artifact selection, planning/contracts and Autopilot consume the selected mode without weakening mandatory controls;
-- add mode-aware documentation behavior;
-- verify migrations, cross-mode compatibility and real host behavior;
-- obtain Product Owner acceptance before any release claim.
+### Development Modes
 
-Track this work in [Issue #50](https://github.com/eybersjp/development-kit/issues/50).
+- five developer-facing methodologies with Balanced as the default;
+- revisioned project-owned mode state and explicit mode-change history;
+- deterministic policy resolution and recommendation;
+- mode-aware specification, artifact and planning behavior;
+- immutable Development Contract mode snapshots;
+- Maintenance & Evolution repository-audit obligations;
+- preservation of all mandatory reliability, evidence, safety and Product Owner controls.
+
+Development Modes was integrated through PR #53 after the full Ubuntu/Windows release-validation matrix passed.
+
+### IDEA Authority Hardening
+
+- explicit USER_STATED / USER_CONFIRMED / AI_PROPOSED / RESEARCH_DERIVED / ASSUMED provenance;
+- Product Owner-bound legal transitions and scope decisions;
+- one persisted, fingerprinted numbered interaction at a time;
+- journal-first discovery persistence and restart recovery;
+- hash-chained replay-protection receipts;
+- Product Owner-bound Design Authority disposition;
+- canonical Idea Brief approval tied to exact artifact/discovery/design fingerprints;
+- direct-edit, stale-source, replay and corruption fail-closed behavior.
+
+IDEA Authority Hardening was integrated through PR #54 after the full Ubuntu/Windows release-validation matrix passed.
 
 ---
 

@@ -37,7 +37,7 @@ DKF already includes the foundations of the reliability-control-plane model:
 - token/context efficiency through scoped authority, compact role prompts, measurable context budgets, and structured reference-first handoffs;
 - adversarial regression coverage based on real development failures.
 
-These are implemented capabilities in the current release line. Development Modes is active unreleased work tracked in Issue #50; it must not be presented as shipped until its integration and acceptance gates pass. The roadmap below describes later evolution and must not be interpreted as functionality already present in v0.11.1.
+These are implemented capabilities in the published v0.11.1 release line. Current `main` additionally contains release-gated Development Modes and IDEA Authority Hardening; they are integrated source capabilities but must not be presented as published v0.11.1/npm functionality until a subsequent versioned release is created. The roadmap below describes later evolution and likewise must not be interpreted as already-published functionality.
 
 ---
 

@@ -1,15 +1,15 @@
 # Development Kit Project Memory
 
-## Current Released Baseline
+## Published Baseline
 
-- **Current release:** v0.11.1 (released 30 September 2026).
-- **Package version on `main`:** 0.11.1.
+- **Current published release:** v0.11.1 (30 September 2026).
+- **Package version on `main`:** 0.11.1 until the next explicit versioned release.
 - **Core lifecycle:** `UNDERSTAND → DEFINE → DESIGN → PLAN → IMPLEMENT → VERIFY → REVIEW → SIMPLIFY → COMPLETE`.
 - **Public command surface:** 16 workflow commands.
 - **Engineering skills:** 48.
-- **Primary product position:** DKF is the reliability control plane for agentic software development — **AI can write it. DKF proves it.**
+- **Primary position:** DKF is the reliability control plane for agentic software development — **AI can write it. DKF proves it.**
 
-## Shipped Reliability Controls
+## Published v0.11.1 Reliability Controls
 
 - Development Contracts with authoritative-source fingerprints.
 - Independent verification and deterministic `BLOCKED / PENDING / ACCEPTED` acceptance.
@@ -23,34 +23,45 @@
 - **Live UI Preview & Visual Verification** (v0.11.1): UI-context preview arming, declared dev-server start/reuse, provider-neutral browser opening, ownership-safe shutdown and VERIFY-stage browser evidence.
 - **Token & Context Efficiency Hardening** (v0.11.1): section-aware source materialization, token profiles, compact role contexts and CI token budgets.
 
-## Current Open Engineering Work
+## Integrated Post-v0.11.1 Mainline Work
 
-### Development Modes — Issue #50
+### Development Modes
 
-The original implementation is preserved in historical draft PRs #42 and #43, but those branches predate v0.11.0/v0.11.1 and must not be merged directly.
+Integrated through PR #53; Issue #50 is completed.
 
-Required completion:
-1. Reconcile and independently verify Increment 001 policy architecture.
-2. Reconcile and independently verify Increment 002 initialization/persistence.
-3. Implement Increment 003: selected mode is consumed by lifecycle, artifact selection, planning/contracts and Autopilot.
-4. Implement Increment 004: mode-aware documentation/artifact behavior.
-5. Implement Increment 005: migrations, cross-mode compatibility and real host acceptance.
-6. Preserve mandatory reliability/safety controls regardless of selected methodology.
+- Modes: Rapid, Balanced, Specification-Driven, Documentation-Driven and Maintenance & Evolution.
+- Project mode state is revisioned, persisted and explicitly change-controlled.
+- Mode policy affects specification/artifact/planning depth but cannot weaken mandatory DKF controls.
+- New Development Contracts bind an immutable mode snapshot and fingerprint; later mode changes affect future contracts only.
+- Historical pre-v0.11 PRs #42/#43 are archival evidence and must not be merged directly.
+- Final PR #53 validation passed the full Ubuntu and Windows `npm run release:validate` matrix.
 
-### IDEA authority hardening — Issue #51
+### IDEA Authority Hardening
 
-The supersession audit of PR #35 is complete. Current v0.11.1 retains persistent/fingerprinted Product Owner decisions and fail-closed numbered decision menus, but several older protections are missing or weaker: runtime IDEA workflow persistence, strict requirement-origin transitions, exact pending-interaction fingerprints, append-only replay protection, crash-safe discovery journaling and Idea Brief approval binding to discovery revision. These protections must be ported as bounded current-generation changes; PR #35 itself must not be merged directly.
+Integrated through PR #54; Issue #51 is completed.
 
-## Repository Maintenance State
+- Requirements carry explicit provenance: USER_STATED, USER_CONFIRMED, AI_PROPOSED, RESEARCH_DERIVED or ASSUMED.
+- Authoritative requirement/question/scope/design/approval transitions require explicit Product Owner authority.
+- IDEA presents one persisted numbered interaction at a time and requires its exact fingerprint for consumption.
+- Discovery uses journal-first, hash-chained persistence with safe restart recovery and corruption fail-closed behavior.
+- Interaction consumption uses hash-chained receipts to prevent replay.
+- Design applicability/disposition is Product Owner-bound; caller-supplied mock authority state is not accepted.
+- Canonical `docs/01-concept/idea-brief.md` approval is bound to exact artifact, discovery and design fingerprints.
+- Direct edits, stale source changes, replay attempts and authority-chain corruption invalidate or block progression.
+- Historical PR #35 is archival behavioral evidence and must not be merged directly.
+- Final PR #54 validation passed the full Ubuntu and Windows `npm run release:validate` matrix, including the dedicated IDEA adversarial suite.
 
-- PR #41 Live UI Preview & Token Efficiency is merged and shipped as v0.11.1.
-- Production-readiness Issue #44 is superseded by the v0.11.1 release plus current Issues #50 and #51.
-- Old release-era draft PRs are archival evidence, not current release candidates.
-- Canonical README, strategy, roadmap, release notes and this memory file must identify v0.11.1 as the current released baseline.
-- Future roadmap version numbers start at **v0.12** because v0.11.0 and v0.11.1 are already released.
+## Repository Reconciliation
+
+- Historical draft PRs #12, #35, #42 and #43 are closed and preserved only as archival evidence.
+- Production-readiness Issue #44 is closed as superseded by the v0.11.1 release.
+- Development Modes Issue #50 and IDEA Authority Issue #51 are completed and closed.
+- Canonical README, strategy, roadmap, release notes and changelog distinguish **published v0.11.1** from post-release functionality integrated on `main`.
+- GitHub Actions are maintained on the current major versions identified by repository dependency automation to avoid deprecated action runtimes.
+- Remote historical branches may remain until branch refs are explicitly deleted; their existence is not authority for current implementation state.
 
 ## Release Discipline
 
-- Green automated tests alone do not authorize release.
-- Do not claim a capability is shipped until its integration, independent verification, required reviews and Product Owner gates pass.
+- Green automated tests alone do not authorize publication.
+- Do not claim post-v0.11.1 mainline functionality is published until version, tag, GitHub Release and package publication gates are explicitly completed.
 - After any release-impacting change, run the full release-validation/package-consumer gates on the final merge base and verify the published distribution.