spec-kitty-cli 3.0.0__tar.gz → 3.0.1__tar.gz

{spec_kitty_cli-3.0.0 → spec_kitty_cli-3.0.1}/.gitignore

@@ -130,3 +130,5 @@ tmp/**
 pytest-of-*/
 .kittify/missions/__pycache__/
 .spec-kitty/
+.claude/
+.agent/

{spec_kitty_cli-3.0.0 → spec_kitty_cli-3.0.1}/CHANGELOG.md

@@ -11,6 +11,14 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 _No unreleased changes._
 
+## [3.0.1] - 2026-03-31
+
+### Fixed
+
+- **Canonical status hard cutover completed.** Work-package lane state is now consistently sourced from `status.events.jsonl` across active CLI commands, packaged task tooling, templates, docs, and standalone helpers. Frontmatter lane fallbacks and `lane=` body-log writes are removed from active 3.0 flows.
+- **Canonical bootstrap and hard-fail behavior hardened.** `finalize-tasks` now seeds canonical `planned` state for generated WPs, while runtime commands fail explicitly when canonical status is missing instead of silently reconstructing it from abandoned frontmatter state.
+- **Release automation updated for 3.x.** GitHub release validation, maintainer docs, and workflow tag handling now use semantic `vX.Y.Z` tags generically, so `v3.0.1` publishes correctly to GitHub Releases and PyPI.
+
 ## [3.0.0] - 2026-03-30
 
 ### Breaking Changes

{spec_kitty_cli-3.0.0 → spec_kitty_cli-3.0.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: spec-kitty-cli
-Version: 3.0.0
+Version: 3.0.1
 Summary: Spec Kitty, a tool for Specification Driven Development (SDD) agentic projects, with kanban and git worktree isolation.
 Project-URL: Repository, https://github.com/Priivacy-ai/spec-kitty
 Project-URL: Issues, https://github.com/Priivacy-ai/spec-kitty/issues
@@ -185,18 +185,17 @@ graph LR
 
 </div>
 
-**Current stable release line:** `v2.1.1` (`main`, GitHub Releases, and PyPI)
+**Current stable release line:** `v3.0.1` (`main`, GitHub Releases, and PyPI)
 
-**2.1.1 highlights:**
-- Hotfix for PyPI wheels to bundle the canonical doctrine skill pack correctly
-- Upgrade repair migration for `2.1.0` projects that missed the managed skill pack
-- Release guardrails now fail if a wheel omits doctrine files or bundled skills
+**3.0.1 highlights:**
+- Canonical status hard cutover completed: active runtime paths no longer fall back to WP frontmatter lane state
+- `finalize-tasks` bootstraps canonical `planned` state for generated work packages
+- Release automation and maintainer tooling now accept semantic `vX.Y.Z` tags for 3.x publishing
 
-**2.1.0 highlights:**
-- Agent Skills Pack with bundled skills, installer/verification flow, and upgrade migration coverage
-- Structured requirement mapping from requirements into work-package planning
-- Deterministic branch intent injection in planning templates
-- `1.x` is now deprecated and retained only as `1.x-maintenance` for critical fixes
+**3.0.0 highlights:**
+- Event log is now the sole authority for mutable work-package status
+- Explicit feature targeting, MissionContext identity, and ownership manifests land on the 3.x stable line
+- Sparse checkout is removed in favor of in-repo planning artifacts and standard worktrees
 
 **Jump to:**
 [Getting Started](#-getting-started-complete-workflow) •
@@ -210,16 +209,16 @@ graph LR
 
 ## 📌 Release Track
 
-Spec Kitty now uses `main` as the stable `2.x` release line.
+Spec Kitty now uses `main` as the stable `3.x` release line.
 The former `1.x` line is deprecated and moves to `1.x-maintenance` for maintenance-only fixes.
 
 | Branch | Version | Status | Install |
 |--------|---------|--------|---------|
-| **main** | **2.1.x** | Current stable line | `pip install spec-kitty-cli` |
+| **main** | **3.0.x** | Current stable line | `pip install spec-kitty-cli` |
 | **1.x-maintenance** | **1.x** | Deprecated, maintenance-only | Install from a pinned maintenance tag or source checkout |
 
 **For users:** install the stable line from PyPI with `pip install spec-kitty-cli`.
-**For existing 1.x users:** migrate to `2.1.x` where possible; `1.x-maintenance` is only for critical maintenance and will no longer publish new PyPI releases.
+**For existing 1.x or 2.x users:** migrate to `3.0.x` where possible; `1.x-maintenance` is only for critical maintenance and will no longer publish new PyPI releases.
 
 ---
 
@@ -1237,10 +1236,10 @@ cat .kittify/metadata.yaml
 If you encounter issues with an agent, please open an issue so we can refine the integration.
 
 <details>
-<summary><h2>🚀 Releasing 2.x on GitHub and PyPI (Maintainers)</h2></summary>
+<summary><h2>🚀 Releasing Stable Versions on GitHub and PyPI (Maintainers)</h2></summary>
 
-The stable `2.x` line now lives on `main` and publishes from semantic tags in the form `v2.<minor>.<patch>`.
-Starting with `2.1.0`, the release workflow publishes both GitHub release artifacts and the PyPI package.
+The stable `3.x` line now lives on `main` and publishes from semantic tags in the form `vX.Y.Z`.
+The release workflow publishes both GitHub release artifacts and the PyPI package.
 
 ### 0. One-Time Setup
 
@@ -1261,7 +1260,7 @@ git checkout -b release/vX.Y.Z
 ### 2. Validate Locally
 
 ```bash
-python scripts/release/validate_release.py --mode branch --tag-pattern "v2.*.*"
+python scripts/release/validate_release.py --mode branch --tag-pattern "v*.*.*"
 python -m pytest
 python -m build
 twine check dist/*
@@ -1298,8 +1297,8 @@ python -m pip index versions spec-kitty-cli
 
 ### Guardrails
 
-- `release-readiness.yml`: runs on PRs to `main` (and `2.x` during the cutover window) to validate version/changelog/tests.
-- `release.yml`: runs on `v2.*.*` tags and performs:
+- `release-readiness.yml`: runs on PRs to `main` (and `2.x` if the maintenance branch is still active) to validate version/changelog/tests.
+- `release.yml`: runs on `v*.*.*` tags and performs:
   - test execution
   - release metadata validation
   - artifact build and checksums
@@ -1309,7 +1308,7 @@ python -m pip index versions spec-kitty-cli
 ### Troubleshooting
 
 **Validation fails**: "Version does not advance beyond latest tag"
-- Check latest tag: `git tag --list 'v2.*.*' --sort=-version:refname | head -1`
+- Check latest tag: `git tag --list 'v*.*.*' --sort=-version:refname | head -1`
 - Bump `pyproject.toml` to a higher semantic version
 
 **Validation fails**: "CHANGELOG.md lacks a populated section"

{spec_kitty_cli-3.0.0 → spec_kitty_cli-3.0.1}/README.md

@@ -96,18 +96,17 @@ graph LR
 
 </div>
 
-**Current stable release line:** `v2.1.1` (`main`, GitHub Releases, and PyPI)
+**Current stable release line:** `v3.0.1` (`main`, GitHub Releases, and PyPI)
 
-**2.1.1 highlights:**
-- Hotfix for PyPI wheels to bundle the canonical doctrine skill pack correctly
-- Upgrade repair migration for `2.1.0` projects that missed the managed skill pack
-- Release guardrails now fail if a wheel omits doctrine files or bundled skills
+**3.0.1 highlights:**
+- Canonical status hard cutover completed: active runtime paths no longer fall back to WP frontmatter lane state
+- `finalize-tasks` bootstraps canonical `planned` state for generated work packages
+- Release automation and maintainer tooling now accept semantic `vX.Y.Z` tags for 3.x publishing
 
-**2.1.0 highlights:**
-- Agent Skills Pack with bundled skills, installer/verification flow, and upgrade migration coverage
-- Structured requirement mapping from requirements into work-package planning
-- Deterministic branch intent injection in planning templates
-- `1.x` is now deprecated and retained only as `1.x-maintenance` for critical fixes
+**3.0.0 highlights:**
+- Event log is now the sole authority for mutable work-package status
+- Explicit feature targeting, MissionContext identity, and ownership manifests land on the 3.x stable line
+- Sparse checkout is removed in favor of in-repo planning artifacts and standard worktrees
 
 **Jump to:**
 [Getting Started](#-getting-started-complete-workflow) •
@@ -121,16 +120,16 @@ graph LR
 
 ## 📌 Release Track
 
-Spec Kitty now uses `main` as the stable `2.x` release line.
+Spec Kitty now uses `main` as the stable `3.x` release line.
 The former `1.x` line is deprecated and moves to `1.x-maintenance` for maintenance-only fixes.
 
 | Branch | Version | Status | Install |
 |--------|---------|--------|---------|
-| **main** | **2.1.x** | Current stable line | `pip install spec-kitty-cli` |
+| **main** | **3.0.x** | Current stable line | `pip install spec-kitty-cli` |
 | **1.x-maintenance** | **1.x** | Deprecated, maintenance-only | Install from a pinned maintenance tag or source checkout |
 
 **For users:** install the stable line from PyPI with `pip install spec-kitty-cli`.
-**For existing 1.x users:** migrate to `2.1.x` where possible; `1.x-maintenance` is only for critical maintenance and will no longer publish new PyPI releases.
+**For existing 1.x or 2.x users:** migrate to `3.0.x` where possible; `1.x-maintenance` is only for critical maintenance and will no longer publish new PyPI releases.
 
 ---
 
@@ -1148,10 +1147,10 @@ cat .kittify/metadata.yaml
 If you encounter issues with an agent, please open an issue so we can refine the integration.
 
 <details>
-<summary><h2>🚀 Releasing 2.x on GitHub and PyPI (Maintainers)</h2></summary>
+<summary><h2>🚀 Releasing Stable Versions on GitHub and PyPI (Maintainers)</h2></summary>
 
-The stable `2.x` line now lives on `main` and publishes from semantic tags in the form `v2.<minor>.<patch>`.
-Starting with `2.1.0`, the release workflow publishes both GitHub release artifacts and the PyPI package.
+The stable `3.x` line now lives on `main` and publishes from semantic tags in the form `vX.Y.Z`.
+The release workflow publishes both GitHub release artifacts and the PyPI package.
 
 ### 0. One-Time Setup
 
@@ -1172,7 +1171,7 @@ git checkout -b release/vX.Y.Z
 ### 2. Validate Locally
 
 ```bash
-python scripts/release/validate_release.py --mode branch --tag-pattern "v2.*.*"
+python scripts/release/validate_release.py --mode branch --tag-pattern "v*.*.*"
 python -m pytest
 python -m build
 twine check dist/*
@@ -1209,8 +1208,8 @@ python -m pip index versions spec-kitty-cli
 
 ### Guardrails
 
-- `release-readiness.yml`: runs on PRs to `main` (and `2.x` during the cutover window) to validate version/changelog/tests.
-- `release.yml`: runs on `v2.*.*` tags and performs:
+- `release-readiness.yml`: runs on PRs to `main` (and `2.x` if the maintenance branch is still active) to validate version/changelog/tests.
+- `release.yml`: runs on `v*.*.*` tags and performs:
   - test execution
   - release metadata validation
   - artifact build and checksums
@@ -1220,7 +1219,7 @@ python -m pip index versions spec-kitty-cli
 ### Troubleshooting
 
 **Validation fails**: "Version does not advance beyond latest tag"
-- Check latest tag: `git tag --list 'v2.*.*' --sort=-version:refname | head -1`
+- Check latest tag: `git tag --list 'v*.*.*' --sort=-version:refname | head -1`
 - Bump `pyproject.toml` to a higher semantic version
 
 **Validation fails**: "CHANGELOG.md lacks a populated section"

spec_kitty_cli-3.0.1/kitty-specs/059-saas-mediated-cli-tracker-reflow/tasks/README.md

@@ -0,0 +1,75 @@
+# Tasks Directory
+
+This directory contains work package (WP) prompt files with lane status in frontmatter.
+
+## Directory Structure (v0.9.0+)
+
+```
+tasks/
+├── WP01-setup-infrastructure.md
+├── WP02-user-authentication.md
+├── WP03-api-endpoints.md
+└── README.md
+```
+
+All WP files are stored flat in `tasks/`. The lane (planned, doing, for_review, approved, done) is stored in the YAML frontmatter `lane:` field.
+
+## Work Package File Format
+
+Each WP file **MUST** use YAML frontmatter:
+
+```yaml
+---
+work_package_id: "WP01"
+title: "Work Package Title"
+lane: "planned"
+dependencies: []
+planning_base_branch: "2.x"
+merge_target_branch: "2.x"
+branch_strategy: "Planning artifacts were generated on 2.x; completed changes must merge back into 2.x."
+subtasks:
+  - "T001"
+  - "T002"
+phase: "Phase 1 - Setup"
+assignee: ""
+agent: ""
+shell_pid: ""
+review_status: ""
+reviewed_by: ""
+review_feedback: ""
+history:
+  - timestamp: "2025-01-01T00:00:00Z"
+    lane: "planned"
+    agent: "system"
+    action: "Prompt generated via /spec-kitty.tasks"
+---
+
+# Work Package Prompt: WP01 – Work Package Title
+
+[Content follows...]
+```
+
+## Valid Lane Values
+
+- `planned` - Ready for implementation
+- `doing` - Currently being worked on
+- `for_review` - Awaiting review
+- `approved` - Review passed; awaiting merge-complete recording
+- `done` - Completed
+
+## Moving Between Lanes
+
+Use the CLI (updates frontmatter only, no file movement):
+```bash
+spec-kitty agent tasks move-task <WPID> --to <lane>
+```
+
+Example:
+```bash
+spec-kitty agent tasks move-task WP01 --to doing
+```
+
+## File Naming
+
+- Format: `WP01-kebab-case-slug.md`
+- Examples: `WP01-setup-infrastructure.md`, `WP02-user-auth.md`

spec_kitty_cli-3.0.1/kitty-specs/060-canonical-status-model-cleanup/tasks/README.md

@@ -0,0 +1,65 @@
+# Tasks Directory
+
+This directory contains work package (WP) prompt files with static definitions in frontmatter.
+
+## Directory Structure
+
+```
+tasks/
+├── WP01-setup-infrastructure.md
+├── WP02-user-authentication.md
+├── WP03-api-endpoints.md
+└── README.md
+```
+
+All WP files are stored flat in `tasks/`.
+
+## Status Authority
+
+WP status (lane) is NOT stored in frontmatter. The sole authority for WP lane state is `status.events.jsonl` in the feature directory, materialized as `status.json` by the reducer.
+
+- To read WP status: `spec-kitty agent tasks status`
+- To move a WP: `spec-kitty agent tasks move-task <WPID> --to <lane>`
+
+Both commands operate on the canonical event log, not on WP files.
+
+## Work Package File Format
+
+Each WP file uses YAML frontmatter for **static definition only**:
+
+```yaml
+---
+work_package_id: "WP01"
+title: "Work Package Title"
+dependencies: []
+planning_base_branch: "main"
+merge_target_branch: "main"
+branch_strategy: "Branch from main."
+subtasks:
+  - "T001"
+  - "T002"
+execution_mode: "code_change"
+owned_files:
+  - "src/myapp/feature.py"
+authoritative_surface: "src/myapp/"
+requirement_refs:
+  - "FR-001"
+history:
+  - at: "2026-01-01T00:00:00Z"
+    actor: "planner"
+    action: "Prompt generated via /spec-kitty.tasks"
+---
+
+# Work Package Prompt: WP01 - Work Package Title
+
+[Content follows...]
+```
+
+Frontmatter does NOT include `lane`, `review_status`, `reviewed_by`, `review_feedback`, or `progress`. Those are managed by the canonical status model.
+
+Operational metadata (`agent`, `assignee`, `shell_pid`) may be present for runtime coordination.
+
+## File Naming
+
+- Format: `WP01-kebab-case-slug.md`
+- Examples: `WP01-setup-infrastructure.md`, `WP02-user-auth.md`

{spec_kitty_cli-3.0.0 → spec_kitty_cli-3.0.1}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "spec-kitty-cli"
-version = "3.0.0"
+version = "3.0.1"
 description = "Spec Kitty, a tool for Specification Driven Development (SDD) agentic projects, with kanban and git worktree isolation."
 readme = "README.md"
 license = { file = "LICENSE" }

{spec_kitty_cli-3.0.0 → spec_kitty_cli-3.0.1}/scripts/release/README.md

@@ -1,14 +1,14 @@
 # Release Scripts
 
 This directory contains helper scripts that keep local release checks aligned with the
-automated GitHub-only release pipeline for the `2.x` branch.
+automated release pipeline for stable releases from `main`.
 
-## 2.x Release Scope
+## Stable Release Scope
 
-- Branch: `2.x`
+- Branch: `main`
 - Versioning: semantic versions (`X.Y.Z`) in `pyproject.toml`
-- Tags: `v2.<minor>.<patch>`
-- Publication target: GitHub Releases only (no PyPI publish from `2.x`)
+- Tags: `vX.Y.Z`
+- Publication targets: GitHub Releases and PyPI
 
 ## Scripts
 
@@ -21,10 +21,10 @@ version progression relative to existing tags.
 
 ```bash
 # Branch mode (for PRs and local development)
-python scripts/release/validate_release.py --mode branch --tag-pattern "v2.*.*"
+python scripts/release/validate_release.py --mode branch --tag-pattern "v*.*.*"
 
 # Tag mode (for release workflow)
-python scripts/release/validate_release.py --mode tag --tag v2.0.0 --tag-pattern "v2.*.*"
+python scripts/release/validate_release.py --mode tag --tag v3.0.1 --tag-pattern "v*.*.*"
 ```
 
 #### What it validates
@@ -32,7 +32,7 @@ python scripts/release/validate_release.py --mode tag --tag v2.0.0 --tag-pattern
 - `pyproject.toml` version is valid semantic version (`X.Y.Z`)
 - `CHANGELOG.md` contains populated section for that version
 - Version advances beyond latest existing release tag
-- In tag mode: tag matches version (for example `v2.0.0` <-> `2.0.0`)
+- In tag mode: tag matches version (for example `v3.0.1` <-> `3.0.1`)
 
 ### `extract_changelog.py`
 
@@ -44,8 +44,8 @@ python scripts/release/extract_changelog.py 2.0.0
 
 ## Workflow Integration
 
-- PR checks: `.github/workflows/release-readiness.yml` (targets `2.x`)
-- Tag releases: `.github/workflows/release.yml` (triggers on `v2.*.*`)
+- PR checks: `.github/workflows/release-readiness.yml`
+- Tag releases: `.github/workflows/release.yml` (triggers on `v*.*.*`)
 
 Release workflow sequence:
 
@@ -59,11 +59,11 @@ Release workflow sequence:
 
 ```bash
 # 1) prepare version + changelog
-vim pyproject.toml   # version = "2.0.0"
-vim CHANGELOG.md     # add ## [2.0.0] - YYYY-MM-DD
+vim pyproject.toml   # version = "3.0.1"
+vim CHANGELOG.md     # add ## [3.0.1] - YYYY-MM-DD
 
 # 2) validate
-python scripts/release/validate_release.py --mode branch --tag-pattern "v2.*.*"
+python scripts/release/validate_release.py --mode branch --tag-pattern "v*.*.*"
 python -m pytest
 python -m build
 twine check dist/*
@@ -71,9 +71,9 @@ twine check dist/*
 # 3) clean build artifacts
 rm -rf dist/ build/
 
-# 4) merge to 2.x, then tag
-git tag v2.0.0 -m "Release 2.0.0"
-git push origin v2.0.0
+# 4) merge to main, then tag
+git tag v3.0.1 -m "Release 3.0.1"
+git push origin v3.0.1
 ```
 
 ## Troubleshooting
@@ -81,7 +81,7 @@ git push origin v2.0.0
 ### Version does not advance
 
 ```bash
-git tag --list 'v2.*.*' --sort=-version:refname | head -1
+git tag --list 'v*.*.*' --sort=-version:refname | head -1
 ```
 
 Then bump `pyproject.toml` to a higher semantic version.
@@ -91,7 +91,7 @@ Then bump `pyproject.toml` to a higher semantic version.
 Add:
 
 ```markdown
-## [2.0.0] - 2026-02-22
+## [3.0.1] - 2026-03-31
 ```
 
 with non-empty notes below the heading.
@@ -101,10 +101,10 @@ with non-empty notes below the heading.
 If tag and `pyproject.toml` do not match:
 
 ```bash
-git tag -d v2.0.0
-git push origin :refs/tags/v2.0.0
-git tag v2.0.0 -m "Release 2.0.0"
-git push origin v2.0.0
+git tag -d v3.0.1
+git push origin :refs/tags/v3.0.1
+git tag v3.0.1 -m "Release 3.0.1"
+git push origin v3.0.1
 ```
 
 ## Testing

{spec_kitty_cli-3.0.0 → spec_kitty_cli-3.0.1}/src/doctrine/missions/documentation/templates/task-prompt-template.md

@@ -4,38 +4,30 @@ subtasks:
   - "Txxx"
 title: "Replace with work package title"
 phase: "Phase N - Replace with phase name"
-lane: "planned"  # DO NOT EDIT - use: spec-kitty agent tasks move-task <WPID> --to <lane>
-assignee: ""      # Optional friendly name when in doing/for_review
+assignee: ""      # Optional friendly name when claimed/in_progress
 agent: ""         # CLI agent identifier (claude, codex, etc.)
-shell_pid: ""     # PID captured when the task moved to the current lane
-review_status: "" # empty | has_feedback | acknowledged (populated by reviewers/implementers)
-reviewed_by: ""   # Agent ID of the reviewer (if reviewed)
+shell_pid: ""     # PID captured when the task was claimed
 history:
-  - timestamp: "{{TIMESTAMP}}"
-    lane: "planned"
-    agent: "system"
-    shell_pid: ""
+  - at: "{{TIMESTAMP}}"
+    actor: "system"
     action: "Prompt generated via /spec-kitty.tasks"
 ---
 
 # Work Package Prompt: {{work_package_id}} – {{title}}
 
-## ⚠️ IMPORTANT: Review Feedback Status
+## ⚠️ IMPORTANT: Review Feedback
 
 **Read this first if you are implementing this task!**
 
-- **Has review feedback?**: Check the `review_status` field above. If it says `has_feedback`, scroll to the **Review Feedback** section immediately (right below this notice).
+- **Has review feedback?**: Check the `review_ref` field in the event log (via `spec-kitty agent status` or the Activity Log below).
 - **You must address all feedback** before your work is complete. Feedback items are your implementation TODO list.
-- **Mark as acknowledged**: When you understand the feedback and begin addressing it, update `review_status: acknowledged` in the frontmatter.
 - **Report progress**: As you address each feedback item, update the Activity Log explaining what you changed.
 
 ---
 
 ## Review Feedback
 
-> **Populated by `/spec-kitty.review`** – Reviewers add detailed feedback here when work needs changes. Implementation must address every item listed below before returning for re-review.
-
-*[This section is empty initially. Reviewers will populate it if the work is returned from review. If you see feedback here, treat each item as a must-do before completion.]*
+*[If this WP was returned from review, the reviewer feedback reference appears in the Activity Log below or in the status event log.]*
 
 ---
 
@@ -95,53 +87,44 @@ Use language identifiers in code blocks: ````python`,````bash`
 
 **When adding an entry**:
 
-1. Scroll to the bottom of this file (Activity Log section below "Valid lanes")
+1. Scroll to the bottom of this Activity Log section
 2. **APPEND the new entry at the END** (do NOT prepend or insert in middle)
-3. Use exact format: `- YYYY-MM-DDTHH:MM:SSZ – agent_id – lane=<lane> – <action>`
+3. Use exact format: `- YYYY-MM-DDTHH:MM:SSZ – agent_id – <action>`
 4. Timestamp MUST be current time in UTC (check with `date -u "+%Y-%m-%dT%H:%M:%SZ"`)
-5. Lane MUST match the frontmatter `lane:` field exactly
-6. Agent ID should identify who made the change (claude-sonnet-4-5, codex, etc.)
+5. Agent ID should identify who made the change (claude-sonnet-4-5, codex, etc.)
 
 **Format**:
 
 ```
-- YYYY-MM-DDTHH:MM:SSZ – <agent_id> – lane=<lane> – <brief action description>
+- YYYY-MM-DDTHH:MM:SSZ – <agent_id> – <brief action description>
 ```
 
 **Example (correct chronological order)**:
 
 ```
-- 2026-01-12T10:00:00Z – system – lane=planned – Prompt created
-- 2026-01-12T10:30:00Z – claude – lane=doing – Started implementation
-- 2026-01-12T11:00:00Z – codex – lane=for_review – Implementation complete, ready for review
-- 2026-01-12T11:30:00Z – claude – lane=done – Review passed, all tests passing  ← LATEST (at bottom)
+- 2026-01-12T10:00:00Z – system – Prompt created
+- 2026-01-12T10:30:00Z – claude – Started implementation
+- 2026-01-12T11:00:00Z – codex – Implementation complete, ready for review
+- 2026-01-12T11:30:00Z – claude – Review passed, all tests passing  ← LATEST (at bottom)
 ```
 
 **Common mistakes (DO NOT DO THIS)**:
 
-- ❌ Adding new entry at the top (breaks chronological order)
-- ❌ Using future timestamps (causes acceptance validation to fail)
-- ❌ Lane mismatch: frontmatter says `lane: "done"` but log entry says `lane=doing`
-- ❌ Inserting in middle instead of appending to end
+- Adding new entry at the top (breaks chronological order)
+- Using future timestamps (causes acceptance validation to fail)
+- Inserting in middle instead of appending to end
 
 **Why this matters**: The acceptance system reads the LAST activity log entry as the current state. If entries are out of order, acceptance will fail even when the work is complete.
 
 **Initial entry**:
 
-- {{TIMESTAMP}} – system – lane=planned – Prompt created.
+- {{TIMESTAMP}} – system – Prompt created.
 
 ---
 
-### Updating Lane Status
-
-To change a work package's lane, either:
-
-1. **Edit directly**: Change the `lane:` field in frontmatter AND append activity log entry (at the end)
-2. **Use CLI**: `spec-kitty agent tasks move-task <WPID> --to <lane> --note "message"` (recommended)
-
-The CLI command updates both frontmatter and activity log automatically.
+### Updating Status
 
-**Valid lanes**: `planned`, `doing`, `for_review`, `done`
+Status is managed via `status.events.jsonl`. Use `spec-kitty agent tasks move-task <WPID> --to <status>` to change WP status.
 
 ### Optional Phase Subdirectories