Normalize agent instructions and workplan frontmatter (STATE-WP-0067)

- Align agent files with on-disk workplan prefixes (infer from workplan ids)
- Set workplan domain to registered domain_slug; add topic_slug where applicable
- Repair frontmatter delimiter formatting; migrate legacy task status literals
- Regenerate AGENTS.md, CLAUDE.md, and .claude/rules from State Hub templates

.claude/rules/agents.md

@@ -0,0 +1,20 @@
+## Kaizen Agents
+
+Specialized agent personas available on demand via the state-hub MCP.
+
+**Discover:** `list_kaizen_agents()` — returns all agents with name, description, category
+**Load:** `get_kaizen_agent("tdd-workflow")` — returns full instructions; read and follow them
+
+Common agents:
+
+| Agent | Category | When to use |
+|-------|----------|-------------|
+| `tdd-workflow` | testing | Step-by-step TDD8 workflow for any feature |
+| `code-refactoring` | quality | Code quality analysis and safe refactoring |
+| `test-maintenance` | testing | Diagnose and fix failing tests |
+| `requirements-engineering` | process | Prevent interface/mock mismatches upfront |
+| `keepaTodofile` | process | Maintain TODO.md during work |
+| `project-management` | process | Track status, determine next steps |
+| `datamodel-optimization` | quality | Optimize dataclasses and data structures |
+
+All 17 agents: call `list_kaizen_agents()` for the full list.

.claude/rules/architecture.md

@@ -1,26 +1,8 @@
 ## Architecture
 
-kaizen-agentic has two distinct layers:
+<!-- TODO: Describe the key design decisions and component structure.
+     Key modules, data flows, external integrations, state machines, etc. -->
 
-### 1. Python framework (`src/kaizen_agentic/`)
+## Quick Reference
 
-- **`core.py`** — `Agent` (abstract base) + `AgentConfig` (dataclass). Tracks performance, supports config updates, implements kaizen interface.
-- **`optimization.py`** — `OptimizationLoop` (runs improvement cycles, detects trends, generates recommendations) + `PerformanceMetrics` (execution time, success rate, quality scores).
-
-### 2. Agent definitions (`agents/` — 17 files)
-
-Markdown instruction sets read and followed by Claude. Not executables. Naming convention: `agent-{name}.md`.
-
-| Category | Agents |
-|----------|--------|
-| Testing | `tdd-workflow`, `test-maintenance`, `testing-efficiency` |
-| Quality | `code-refactoring`, `datamodel-optimization`, `optimization` |
-| Process | `requirements-engineering`, `keepaTodofile`, `keepaChangelog`, `keepaContributingfile`, `project-management`, `priority-evaluation`, `scope-analyst` |
-| Infrastructure | `setupRepository`, `tooling-optimization` |
-| Release | `releaseManager` |
-| Docs | `claude-documentation` |
-| Support | `wisdom-encouragement` |
-
-### Custodian integration
-
-The state-hub MCP resolves the agents directory via `host_paths[hostname]` → `local_path`. Tools: `list_kaizen_agents(category?)`, `get_kaizen_agent(name)`.
+`~/state-hub/mcp_server/TOOLS.md` — MCP tool reference

.claude/rules/credential-routing.md

@@ -0,0 +1,50 @@
+# Credential and access routing
+
+**Audience:** Codex, Claude Code, Grok, and custodian agents that call **llm-connect**
+for inference. Run this check **before** requesting secrets, API keys, SSH access,
+login tokens, or database passwords — in any repo, not only `ops-warden`.
+
+ops-warden **issues SSH certificates only** (`warden sign`, `cert_command`). Every
+other credential need belongs to another subsystem. **Do not** message
+`ops-warden` on State Hub expecting a secret value; the reply is a pointer, not a key.
+
+### Lookup (do this first)
+
+```bash
+warden route find "<describe your need>" --json
+warden route show <catalog-id> --json
+```
+
+Requires the `warden` CLI from `~/ops-warden` (`uv tool install .` or `uv run warden`).
+
+| Agent runtime | How to orient |
+| --- | --- |
+| **Codex / Grok** (shell, HTTP State Hub) | `warden route` commands above; inbox `to_agent=kaizen-agentic` is for coordination, not secret vending |
+| **Claude Code** (MCP when available) | `get_domain_summary("custodian")` for workstreams; **still** use `warden route` for credential ownership |
+| **llm-connect** (inference service) | Never put secret retrieval in prompts; route custody to OpenBao/operator paths surfaced by `warden route` |
+
+### Quick routing table
+
+| I need… | Owner | ops-warden executes? |
+| --- | --- | --- |
+| SSH cert (`adm`/`agt`/`atm`) | ops-warden | **Yes** — `warden sign` |
+| API key, DB password, provider token | OpenBao (`railiance-platform`) | No — route only |
+| Login / OIDC / MFA | key-cape / Keycloak | No — route only |
+| Authorization decision | flex-auth | No — route only |
+| activity-core → issue-core emission | activity-core + issue-core | No — `warden route show activity-core-issue-sink` |
+| SSH tunnel | ops-bridge (+ `cert_command` from warden) | No — route only |
+
+### Anti-patterns (do not do these)
+
+- `POST /messages/` to `ops-warden` asking for `ISSUE_CORE_API_KEY`, `OPENROUTER_API_KEY`, etc.
+- Inventing `warden secret`, `warden login`, `warden bao`, `warden tunnel` — they do not exist
+- Pasting secrets into Git, State Hub, workplans, logs, or chat
+
+### Other capabilities (reuse-surface)
+
+Non-credential capabilities are usually discovered through **reuse-surface** federation
+(`reuse-surface` registry / `capability.*` indexes). Credential routing is inlined in
+every repo's agent instructions because it is high-frequency, high-risk, and easy to
+get wrong.
+
+**Canon:** `~/ops-warden/wiki/CredentialRouting.md` · catalog `~/ops-warden/registry/routing/catalog.yaml`

.claude/rules/first-session.md

@@ -1,11 +1,11 @@
 ## First Session Protocol
 
-Triggered when `get_domain_summary("custodian")` shows **no workstreams**.
+Triggered when `get_domain_summary("agents")` shows **no workstreams**.
 The project is registered but work has not yet been structured.
 
 **Step 1 — Read, don't write**
-- `~/the-custodian/canon/projects/custodian/project_charter_v0.1.md` — purpose, scope
-- `~/the-custodian/canon/projects/custodian/roadmap_v0.1.md` — planned phases
+- `~/the-custodian/canon/projects/agents/project_charter_v0.1.md` — purpose, scope
+- `~/the-custodian/canon/projects/agents/roadmap_v0.1.md` — planned phases
 - Scan repo root: README, directory structure, existing code or docs
 
 **Step 2 — Survey in-progress work**
@@ -17,20 +17,20 @@ roadmap phase. **Wait for approval before creating.**
 
 **Step 4 — Create workplan file first, then DB record (ADR-001)**
 ```
-workplans/kaizen-agentic-WP-NNNN-<slug>.md   ← write this first
+workplans/KAIZEN-WP-NNNN-<slug>.md   ← write this first
 ```
 Then register in the hub:
 ```
-create_workstream(topic_id="cee7bedf-2b48-46ef-8601-006474f2ad7a", title="...", owner="...", description="...")
+create_workstream(topic_id="64418556-3206-457a-ba29-6884b5b12cf3", title="...", owner="...", description="...")
 create_task(workstream_id="<id>", title="...", priority="high|medium|low")
 ```
 
 **Step 5 — Record the setup**
 ```
 add_progress_event(
-    summary="First session: structured custodian into N workstreams, M tasks",
+    summary="First session: structured agents into N workstreams, M tasks",
     event_type="milestone",
-    topic_id="cee7bedf-2b48-46ef-8601-006474f2ad7a",
+    topic_id="64418556-3206-457a-ba29-6884b5b12cf3",
     detail={"workstreams": [...], "tasks_created": M}
 )
 ```

.claude/rules/repo-boundary.md

@@ -2,7 +2,7 @@
 
 This repo owns **kaizen-agentic** only. It does not own:
 
-- State-hub MCP integration code → `the-custodian/state-hub/mcp_server/server.py`
-- Agent discovery tools (`list_kaizen_agents`, `get_kaizen_agent`) → `the-custodian`
-- Custodian coordination and workplan tracking → `the-custodian`
-- Deployment to custodiancore → `ops-bridge`
+<!-- TODO: List what belongs in adjacent repos, e.g.:
+- SSH key management → railiance-infra/
+- State hub code     → state-hub/
+-->

.claude/rules/repo-identity.md

@@ -1,9 +1,5 @@
-## Repo Identity
+**Purpose:** AI-assisted development quality toolchain. Provides pre-commit hooks, CI/CD pipeline automation, usage telemetry, and CLI improvement scaffolding for the custodian domain.
 
-**Purpose:** kaizen-agentic — AI agent development framework embracing kaizen (continuous improvement). Provides 17 specialized Claude Code companion agents plus an OptimizationLoop framework for continuous performance measurement and refinement.
-
-**Domain:** custodian
+**Domain:** agents
 **Repo slug:** kaizen-agentic
-**Topic ID:** cee7bedf-2b48-46ef-8601-006474f2ad7a
-
-**Custodian integration:** This repo is the single source of truth for all kaizen agents. The state-hub MCP exposes `list_kaizen_agents()` and `get_kaizen_agent(name)` tools so any connected session can discover and load agents without a local copy.
+**Topic ID:** 64418556-3206-457a-ba29-6884b5b12cf3

.claude/rules/session-protocol.md

@@ -1,29 +1,50 @@
 ## Session Protocol
 
-State Hub: http://127.0.0.1:8000
+Dev Hub (State Hub API): http://127.0.0.1:8000
+MCP server name in `~/.claude.json`: `dev-hub`
 
 **Step 1 — Orient**
+
+Read the offline-safe brief first — it works without a live hub connection:
+```bash
+cat .custodian-brief.md
 ```
-get_domain_summary("custodian")
+Then call the MCP tool for richer cross-domain context when MCP tools are exposed:
 ```
-If offline: `cd ~/the-custodian/state-hub && make api`
+get_domain_summary("agents")
+```
+If MCP tools are unavailable in the current agent session, use the REST API:
+```bash
+curl -s "http://127.0.0.1:8000/state/summary" | python3 -m json.tool
+```
+If the hub is offline: `cd ~/state-hub && make api`
 
 **Step 2 — Check inbox**
+With MCP tools:
 ```
 get_messages(to_agent="kaizen-agentic", unread_only=True)
 ```
 Mark read with `mark_message_read(message_id)`. Reply or act on coordination
 requests before proceeding.
 
+Without MCP tools:
+```bash
+curl -s "http://127.0.0.1:8000/messages/?to_agent=kaizen-agentic&unread_only=true" \
+  | python3 -m json.tool
+curl -s -X PATCH "http://127.0.0.1:8000/messages/<id>/read" \
+  -H "Content-Type: application/json" -d '{}'
+```
+
 **Step 3 — Scan workplans**
 ```bash
 ls workplans/
 ```
-For each file with `status: active`, note pending `todo`/`in_progress` tasks.
+For each file with `status: ready`, `active`, or `blocked`, note pending
+`wait`/`todo`/`progress` tasks.
 
 **Step 4 — Present brief**
 
-1. **Active workstreams** for `custodian` — title, task counts, blocking decisions
+1. **Active workstreams** for `agents` — title, task counts, blocking decisions
 2. **Pending tasks** from `workplans/` + any `[repo:kaizen-agentic]` hub tasks
 3. **Goal guidance** — if `goal_guidance` in summary:
    - `needs_workplan`: surface as top action — *"Repo goal '{title}' has no workplan yet"*
@@ -39,10 +60,26 @@ If no workstreams: follow First Session Protocol (`first-session.md`).
 > are First Session Protocol only. Work structure belongs in repo files (ADR-001).
 
 **Session close:**
+With MCP tools:
 ```
-add_progress_event(summary="...", topic_id="cee7bedf-2b48-46ef-8601-006474f2ad7a", workstream_id="<uuid>")
+add_progress_event(summary="...", topic_id="64418556-3206-457a-ba29-6884b5b12cf3", workstream_id="<uuid>")
 ```
-If workplan files were modified:
+Without MCP tools:
 ```bash
-cd ~/the-custodian/state-hub && make fix-consistency REPO=kaizen-agentic
+curl -s -X POST http://127.0.0.1:8000/progress/ \
+  -H "Content-Type: application/json" \
+  -d '{"topic_id":"64418556-3206-457a-ba29-6884b5b12cf3","workstream_id":"<uuid>","event_type":"note","summary":"what changed","author":"codex"}'
 ```
+If workplan files were modified, ensure the local copy is up to date first:
+```bash
+git -C <repo_path> pull --ff-only
+cd ~/state-hub && make fix-consistency REPO=kaizen-agentic
+```
+For repos where implementation runs on a remote machine (e.g. CoulombCore),
+use the combined target which pulls before fixing:
+```bash
+cd ~/state-hub && make fix-consistency-remote REPO=kaizen-agentic
+```
+**C-15** (DB task ahead of file) is normal in multi-machine workflows — writeback
+will sync the file to match DB.  **C-16** (repo behind remote) blocks all writes
+until you pull — intentional to prevent clobbering remote progress.

.claude/rules/stack-and-commands.md

@@ -1,43 +1,19 @@
-## Stack and Commands
+## Stack
 
-**Language:** Python 3.8+
-**Package manager:** uv / pip (`.venv/`)
-**Test runner:** pytest
-**Linter/formatter:** flake8 (100-char), black (88-char), mypy (strict)
+<!-- TODO: Fill in language, frameworks, and key dependencies -->
+- **Language:**
+- **Key deps:**
 
-### Essential commands
+## Dev Commands
 
 ```bash
-make setup-complete     # First-time setup: venv + package + dev deps
-source .venv/bin/activate
-make test               # Run full test suite
-make lint               # flake8 linting
-make format             # black formatting
-make clean              # Remove build artifacts
+# TODO: Fill in the standard commands for this repo
+
+# Install dependencies
+
+# Run tests
+
+# Lint / type check
+
+# Build / package (if applicable)
 ```
-
-### TDD workflow
-
-```bash
-make tdd-start ISSUE=X  # Start issue with requirements validation
-make tdd-add-test       # Add test to current workspace
-make tdd-status         # Show workspace state
-make tdd-finish         # Move tests to main suite
-```
-
-### Issue management
-
-```bash
-make issue-list         # All issues (Gitea)
-make issue-list-open    # Open backlog
-make issue-show ISSUE=X # Issue detail
-make issue-create TITLE='...' BODY='...'
-```
-
-Run `make help` to see all available targets.
-
-### Core dependencies (pyproject.toml)
-
-- `pyyaml>=6.0` — YAML config
-- `click>=8.0.0` — CLI framework
-- `pydantic>=2.0.0` — Data validation

.claude/rules/workplan-convention.md

@@ -1,12 +1,40 @@
 ## Workplan Convention (ADR-001)
 
-File location: `workplans/kaizen-agentic-WP-NNNN-<slug>.md`
-ID prefix: `KAIZEN-WP`
+File location: `workplans/KAIZEN-WP-NNNN-<slug>.md`
+ID prefix: `KAIZEN-WP-`
 
 Work items originate as files in this repo **before** being registered in the hub.
 
+Canonical workplan/workstream frontmatter statuses are:
+`proposed`, `ready`, `active`, `blocked`, `backlog`, `finished`, `archived`.
+Use `proposed` for a newly drafted plan, `ready` after review against current
+repo state, and `finished` when implementation is complete. `stalled` and
+`needs_review` are derived health labels, not stored statuses.
+
+Closed workplans may be moved to `workplans/archived/` with a completion-date
+prefix: `YYMMDD-KAIZEN-WP-NNNN-<slug>.md`. The frontmatter id remains
+unchanged; the prefix is only for quick visual reference.
+
+Small opportunistic tasks discovered during another session use **Ad Hoc Tasks**:
+`workplans/ADHOC-YYYY-MM-DD.md`, workstream slug `adhoc-YYYY-MM-DD`, and task ids
+`ADHOC-YYYY-MM-DD-T01`, `T02`, etc. Use adhocs only for low-risk work completed
+directly. Promote anything requiring analysis, design, approval, dependencies, or
+multiple planned phases into a normal workplan.
+
 Ecosystem todos from other agents arrive as `[repo:kaizen-agentic]` hub tasks —
 visible at session start. Pick one up by creating the workplan file, then registering
 the workstream.
 
+Task blocks use this shape:
+
+```task
+id: KAIZEN-WP-NNNN-T01
+status: wait | todo | progress | done | cancel
+priority: high | medium | low
+state_hub_task_id: "<uuid>"         # written by fix-consistency — do not edit
+```
+
+Status progression is `todo` → `progress` → `done`; use `wait` for waiting or
+blocked work and `cancel` for stopped work.
+
 <!-- Ralph Loop rules and HEUREKA sequence: ~/.claude/CLAUDE.md — do not duplicate here -->

.custodian-brief.md

@@ -0,0 +1,18 @@
+<!-- custodian-brief: generated by fix-consistency — do not edit manually -->
+# Custodian Brief — kaizen-agentic
+
+**Domain:** custodian
+**Last synced:** 2026-06-18 13:14 UTC
+**State Hub:** http://127.0.0.1:8000 *(adjust if running on a remote machine)*
+
+## Active Workstreams
+
+*(none — repo may need first-session setup)*
+
+---
+## MCP Orientation (when available)
+
+If the state-hub MCP server is reachable, call:
+`get_domain_summary("custodian")`
+This provides richer cross-domain context.
+If the MCP call fails, use this file as your orientation source.

.flake8

@@ -0,0 +1,11 @@
+[flake8]
+max-line-length = 88
+extend-ignore = E203, W503
+per-file-ignores =
+    tests/*:E501,F841
+exclude =
+    .venv,
+    build,
+    dist,
+    .git,
+    __pycache__

.gitea/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,35 @@
+---
+name: Bug report
+about: Report a defect in kaizen-agentic
+title: "[bug] "
+labels: bug
+---
+
+## Summary
+
+<!-- One sentence describing the problem -->
+
+## Steps to reproduce
+
+1.
+2.
+3.
+
+## Expected behavior
+
+## Actual behavior
+
+## Environment
+
+- OS:
+- Python version:
+- kaizen-agentic version (`kaizen-agentic --version`):
+- Install method (pip / editable / other):
+
+## Logs or CLI output
+
+```
+(paste relevant output)
+```
+
+## Additional context

.gitea/ISSUE_TEMPLATE/config.yaml

@@ -0,0 +1,8 @@
+blank_issues_enabled: false
+contact_links:
+  - name: Feedback guide
+    url: https://gitea.coulomb.social/coulomb/kaizen-agentic/src/branch/main/docs/FEEDBACK.md
+    about: How to submit feedback, bugs, and feature ideas
+  - name: Contributing guide
+    url: https://gitea.coulomb.social/coulomb/kaizen-agentic/src/branch/main/CONTRIBUTING.md
+    about: Development workflow and code standards

.gitea/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,23 @@
+---
+name: Feature request
+about: Suggest an enhancement for kaizen-agentic
+title: "[feature] "
+labels: enhancement
+---
+
+## Problem or opportunity
+
+<!-- What pain point does this address? -->
+
+## Proposed solution
+
+## Alternatives considered
+
+## Scope
+
+- [ ] CLI / framework (`src/kaizen_agentic/`)
+- [ ] Agent definitions (`agents/`)
+- [ ] Documentation / wiki
+- [ ] Ecosystem integration (activity-core, artifact-store, agentic-resources)
+
+## Additional context

.gitea/ISSUE_TEMPLATE/feedback.md

@@ -0,0 +1,21 @@
+---
+name: General feedback
+about: Share experience, ideas, or adoption feedback
+title: "[feedback] "
+labels: feedback
+---
+
+## Context
+
+<!-- How are you using kaizen-agentic? (project type, agents used, workflow) -->
+
+## What worked well
+
+## What was confusing or friction-heavy
+
+## Suggestions
+
+## Optional: metrics / telemetry context
+
+If relevant, note whether you use project metrics (`.kaizen/metrics/`) or Helix Forge
+fleet capture — helps us prioritize integration improvements.

.gitea/workflows/ci.yml

@@ -0,0 +1,38 @@
+name: ci
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+    branches: [main]
+
+jobs:
+  test:
+    runs-on: haskelseed
+    steps:
+      - name: Check out source
+        env:
+          PACKAGE_TOKEN: ${{ secrets.PACKAGE_TOKEN }}
+        run: |
+          git clone --depth 1 \
+            "https://tegwick:${PACKAGE_TOKEN}@gitea.coulomb.social/coulomb/kaizen-agentic.git" \
+            repo
+          cd repo
+          git checkout "${{ gitea.sha }}"
+
+      - name: Install package and dev tools
+        run: |
+          cd repo
+          python3 -m ensurepip --upgrade 2>/dev/null || \
+            curl -sS https://bootstrap.pypa.io/get-pip.py -o /tmp/get-pip.py && python3 /tmp/get-pip.py
+          python3 -m pip install --upgrade pip
+          python3 -m pip install -e ".[dev]"
+
+      - name: Format check (black)
+        run: cd repo && black --check src tests
+
+      - name: Lint (flake8)
+        run: cd repo && flake8 src/ --max-line-length=100
+
+      - name: Run tests
+        run: cd repo && pytest tests/ -q --ignore=tests/test_cli_error_handling.py

.gitea/workflows/publish-python-package.yml

@@ -0,0 +1,41 @@
+name: Publish Python package
+
+on:
+  push:
+    tags:
+      - "v*"
+  workflow_dispatch:
+
+jobs:
+  publish:
+    runs-on: haskelseed
+    steps:
+      - name: Check out source
+        env:
+          PACKAGE_USER: ${{ secrets.PACKAGE_USER }}
+          PACKAGE_TOKEN: ${{ secrets.PACKAGE_TOKEN }}
+        run: |
+          git clone --depth 1 \
+            "https://${PACKAGE_USER}:${PACKAGE_TOKEN}@gitea.coulomb.social/coulomb/kaizen-agentic.git" \
+            repo
+          cd repo
+          git checkout "${{ gitea.sha }}"
+
+      - name: Build and publish
+        env:
+          TWINE_USERNAME: ${{ secrets.PACKAGE_USER }}
+          TWINE_PASSWORD: ${{ secrets.PACKAGE_TOKEN }}
+          PYTHON_KEYRING_BACKEND: keyring.backends.null.Keyring
+        run: |
+          cd repo
+          python3 -m venv .build-venv
+          . .build-venv/bin/activate
+          python -m pip install --upgrade pip build twine
+          python -m build
+          python -m twine check dist/*
+          python -m twine upload \
+            --username "${TWINE_USERNAME}" \
+            --password "${TWINE_PASSWORD}" \
+            --non-interactive \
+            --repository-url https://gitea.coulomb.social/api/packages/coulomb/pypi \
+            dist/*

.gitignore

@@ -42,3 +42,10 @@ venv.bak/
 .coverage
 htmlcov/
 .tox/
+
+# Backup directories created by optimization scripts
+agents_backup_*/
+
+# Project-scoped kaizen runtime state (ADR-002, ADR-004)
+.kaizen/agents/
+.kaizen/metrics/

.kaizen/schedule.yml

@@ -0,0 +1,15 @@
+# Kaizen scheduled agent execution manifest (ADR-005)
+# Engagement: coulomb-loop bootstrap — weekly cadence
+# Regulator promotes cadence per customer engagement policy (ADR-003).
+# Validate with: kaizen-agentic schedule validate
+version: '1'
+timezone: Europe/Berlin
+agents:
+  coach:
+    cadence: weekly
+    cron: 0 9 * * 1
+    enabled: true
+  optimization:
+    cadence: weekly
+    cron: 0 10 * * 1
+    enabled: true

.pre-commit-config.yaml

@@ -0,0 +1,20 @@
+# Pre-commit hooks for kaizen-agentic (WP-0001 T02)
+# Install: pip install pre-commit && pre-commit install
+
+repos:
+  - repo: https://github.com/pre-commit/pre-commit-hooks
+    rev: v5.0.0
+    hooks:
+      - id: trailing-whitespace
+      - id: end-of-file-fixer
+      - id: check-yaml
+        args: [--unsafe]
+      - id: check-added-large-files
+        args: [--maxkb=512]
+
+  - repo: https://github.com/psf/black
+    rev: 24.10.0
+    hooks:
+      - id: black
+        language_version: python3
+

.repo-classification.yaml

@@ -0,0 +1,30 @@
+# Repo classification (Repo Classification Standard v1.0).
+
+repo_classification:
+  standard: Repo Classification Standard
+  version: '1.0'
+  classified_at: '2026-06-22'
+  classified_by: human
+  category: tooling
+  domain: agents
+  secondary_domains:
+  - infotech
+  capability_tags:
+  - orchestration
+  - automation
+  - coordination
+  - knowledge
+  - documentation
+  business_stake:
+  - technology
+  - product
+  - automation
+  - people
+  - intelligence
+  business_mechanics:
+  - intention
+  - coordination
+  - operation
+  - adaptation
+  notes: 'Digital talent-agency framework: agent personas, project memory, improvement loops,
+    CLI tooling. Primary domain agents (AI-native), infotech secondary.'

AGENTS.md

@@ -0,0 +1,219 @@
+# kaizen-agentic — Agent Instructions
+
+## Repo Identity
+
+**Purpose:** AI-assisted development quality toolchain. Provides pre-commit hooks, CI/CD pipeline automation, usage telemetry, and CLI improvement scaffolding for the custodian domain.
+
+**Domain:** agents
+**Repo slug:** kaizen-agentic
+**Topic ID:** `64418556-3206-457a-ba29-6884b5b12cf3`
+**Workplan prefix:** `KAIZEN-WP-`
+
+---
+
+## State Hub Integration
+
+The Custodian State Hub tracks work across all domains. Interact via HTTP REST —
+there is no MCP server for Codex agents.
+
+| Context | URL |
+|---------|-----|
+| Local workstation | `http://127.0.0.1:8000` |
+| Remote via tunnel | `http://127.0.0.1:18000` |
+
+### Orient at session start
+
+```bash
+# Offline brief — works without hub connection
+cat .custodian-brief.md
+
+# Active workstreams for this domain
+curl -s "http://127.0.0.1:8000/workstreams/?topic_id=64418556-3206-457a-ba29-6884b5b12cf3&status=active" \
+  | python3 -m json.tool
+
+# Check inbox
+curl -s "http://127.0.0.1:8000/messages/?to_agent=kaizen-agentic&unread_only=true" \
+  | python3 -m json.tool
+```
+
+Mark a message read:
+```bash
+curl -s -X PATCH "http://127.0.0.1:8000/messages/<id>/read" \
+  -H "Content-Type: application/json" -d '{}'
+```
+
+### Log progress (required at session close)
+
+```bash
+curl -s -X POST http://127.0.0.1:8000/progress/ \
+  -H "Content-Type: application/json" \
+  -d '{
+    "summary": "what was done",
+    "event_type": "note",
+    "author": "codex",
+    "workstream_id": "<uuid>",
+    "task_id": "<uuid>"
+  }'
+```
+
+Omit `workstream_id` / `task_id` when not applicable.
+
+### Update task status
+
+```bash
+curl -s -X PATCH "http://127.0.0.1:8000/tasks/<task_id>" \
+  -H "Content-Type: application/json" \
+  -d '{"status": "progress"}'
+# values: wait | todo | progress | done | cancel
+```
+
+### Flag a task for human review
+
+```bash
+curl -s -X PATCH "http://127.0.0.1:8000/tasks/<task_id>" \
+  -H "Content-Type: application/json" \
+  -d '{"needs_human": true, "intervention_note": "reason"}'
+```
+
+---
+
+## Session Protocol
+
+**Start:**
+1. `cat .custodian-brief.md` — domain goal and open workstreams (offline-safe)
+2. Check inbox: `GET /messages/?to_agent=kaizen-agentic&unread_only=true`; mark read
+3. Scan workplans: `ls workplans/` — note `status: ready`, `active`, or `blocked` files and open tasks
+4. Check human-needed tasks: `GET /tasks/?needs_human=true`
+
+**During work:**
+- Update task statuses in workplan files as tasks progress
+- Record significant decisions via `POST /decisions/`
+
+**Close:**
+1. Update workplan file task statuses to reflect progress
+2. Log: `POST /progress/` with a summary of what changed
+3. Note for the custodian operator: after workplan file changes, run from
+   `~/state-hub`:
+   ```bash
+   make fix-consistency REPO=kaizen-agentic
+   ```
+   This syncs task status from files into the hub DB.
+
+---
+
+## Credential and access routing
+
+**Audience:** Codex, Claude Code, Grok, and custodian agents that call **llm-connect**
+for inference. Run this check **before** requesting secrets, API keys, SSH access,
+login tokens, or database passwords — in any repo, not only `ops-warden`.
+
+ops-warden **issues SSH certificates only** (`warden sign`, `cert_command`). Every
+other credential need belongs to another subsystem. **Do not** message
+`ops-warden` on State Hub expecting a secret value; the reply is a pointer, not a key.
+
+### Lookup (do this first)
+
+```bash
+warden route find "<describe your need>" --json
+warden route show <catalog-id> --json
+```
+
+Requires the `warden` CLI from `~/ops-warden` (`uv tool install .` or `uv run warden`).
+
+| Agent runtime | How to orient |
+| --- | --- |
+| **Codex / Grok** (shell, HTTP State Hub) | `warden route` commands above; inbox `to_agent=kaizen-agentic` is for coordination, not secret vending |
+| **Claude Code** (MCP when available) | `get_domain_summary("custodian")` for workstreams; **still** use `warden route` for credential ownership |
+| **llm-connect** (inference service) | Never put secret retrieval in prompts; route custody to OpenBao/operator paths surfaced by `warden route` |
+
+### Quick routing table
+
+| I need… | Owner | ops-warden executes? |
+| --- | --- | --- |
+| SSH cert (`adm`/`agt`/`atm`) | ops-warden | **Yes** — `warden sign` |
+| API key, DB password, provider token | OpenBao (`railiance-platform`) | No — route only |
+| Login / OIDC / MFA | key-cape / Keycloak | No — route only |
+| Authorization decision | flex-auth | No — route only |
+| activity-core → issue-core emission | activity-core + issue-core | No — `warden route show activity-core-issue-sink` |
+| SSH tunnel | ops-bridge (+ `cert_command` from warden) | No — route only |
+
+### Anti-patterns (do not do these)
+
+- `POST /messages/` to `ops-warden` asking for `ISSUE_CORE_API_KEY`, `OPENROUTER_API_KEY`, etc.
+- Inventing `warden secret`, `warden login`, `warden bao`, `warden tunnel` — they do not exist
+- Pasting secrets into Git, State Hub, workplans, logs, or chat
+
+### Other capabilities (reuse-surface)
+
+Non-credential capabilities are usually discovered through **reuse-surface** federation
+(`reuse-surface` registry / `capability.*` indexes). Credential routing is inlined in
+every repo's agent instructions because it is high-frequency, high-risk, and easy to
+get wrong.
+
+**Canon:** `~/ops-warden/wiki/CredentialRouting.md` · catalog `~/ops-warden/registry/routing/catalog.yaml`
+
+<!-- REPO-AGENTS-EXTENSIONS -->
+<!-- Append repo-specific agent instructions below this marker.
+     The state-hub template sync preserves content after this line. -->
+
+---
+
+## Workplan Convention (ADR-001)
+
+Work items originate as files in this repo — not in the hub. The hub is a
+read/cache/index layer that rebuilds from files.
+
+**File location:** `workplans/KAIZEN-WP-NNNN-<slug>.md`
+
+**Archived location:** finished workplans may move to
+`workplans/archived/YYMMDD-KAIZEN-WP-NNNN-<slug>.md`. The `YYMMDD` prefix is
+the completion/archive date; the frontmatter `id` does not change.
+
+**Ad Hoc Tasks:** small opportunistic fixes discovered during a session use
+`workplans/ADHOC-YYYY-MM-DD.md` with task ids `ADHOC-YYYY-MM-DD-T01`, etc. Use
+this only for low-risk work completed directly; create a normal workplan for
+anything needing analysis, design, approval, dependencies, or multiple phases.
+
+**Frontmatter:**
+
+```yaml
+---
+id: KAIZEN-WP-NNNN
+type: workplan
+title: "..."
+domain: agents
+repo: kaizen-agentic
+status: proposed | ready | active | blocked | backlog | finished | archived
+owner: codex
+topic_slug: ...
+created: "YYYY-MM-DD"
+updated: "YYYY-MM-DD"
+state_hub_workstream_id: "<uuid>"   # written by fix-consistency — do not edit
+---
+```
+
+Use `proposed` for a new draft, `ready` after review against current repo
+state, and `finished` after implementation. `stalled` and `needs_review` are
+derived health labels, not frontmatter statuses.
+
+**Task block format** (one per `##` section):
+
+```
+## Task Title
+
+` ` `task
+id: KAIZEN-WP-NNNN-T01
+status: wait | todo | progress | done | cancel
+priority: high | medium | low
+state_hub_task_id: "<uuid>"         # written by fix-consistency — do not edit
+` ` `
+
+Task description text.
+```
+
+Status progression: `todo` → `progress` → `done`; use `wait` for waiting/blocked work and `cancel` for stopped work.
+
+To create a new workplan:
+1. Write the file following the format above
+2. Notify the custodian operator to run `make fix-consistency REPO=kaizen-agentic`
+   (or send a message to the hub agent via `POST /messages/`)

CHANGELOG.md

@@ -7,8 +7,96 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+### Removed
+- **`TODO.md`** — work tracking uses `workplans/` and State Hub (ADR-001); the
+  `keepaTodofile` agent remains available for other projects
+
 ### Added
-- **sys-medic agent**: Linux/Kubernetes node health assessment agent integrated as a standard kaizen-agentic infrastructure agent (KAIZEN-WP-0002 Part 1)
+- **`metrics record --emit-event`** — publishes `kaizen.metrics.recorded` NATS
+  envelope for activity-core event-driven definitions (optional `nats-py` via
+  `pip install 'kaizen-agentic[events]'`)
+- **`schedule init --engagement`** — bootstrap presets for customer engagements
+  (`--bootstrap-cadence hourly|daily|weekly`)
+- **ADR-006** — customer engagement convention (supplier/customer split, playbook)
+- **Playbook v1** — `docs/integrations/customer-engagement-playbook.md`,
+  `customer-engagement-repo-layout.md`, override manifest design
+- **Event contract** — `docs/integrations/kaizen-metrics-recorded-event.md`
+- **Engagement handoff** — `docs/integrations/activity-core-handoff-engagement.md`
+
+## [1.4.0] - 2026-06-18
+
+### Added
+- **Agent authoring & doc generation (WP-0007)** — `kaizen-agentic create-agent`
+  scaffolds a schema-valid agent; `kaizen-agentic docs generate [--check]`
+  refreshes the CLAUDE.md `## Installed Agents` section idempotently
+- **Frontmatter schema validation** — `kaizen-agentic validate` now enforces
+  required `name`/`description`/`category`, a known category, and valid
+  `memory`/`model` values with actionable errors
+
+### Fixed
+- **Idempotent doc regeneration** — `_update_documentation` no longer duplicates
+  the `## Installed Agents` block on each run (regex stopped at the first `###`
+  subheading); rendering is now a shared, idempotent helper
+- **Declared category honoured** — agent frontmatter `category` is authoritative
+  when valid (name/content heuristic is fallback only)
+- **Installed-agent resolution** — `list_installed_agents` reads the frontmatter
+  name, so agents whose filename differs from their name resolve correctly
+
+### Changed
+- **Renamed `agent-project-management.md` → `agent-project-assistant.md`** to
+  satisfy the `agent-<name>.md` convention (frontmatter `name: project-assistant`);
+  eliminates a registry name/filename collision
+
+## [1.3.0] - 2026-06-17
+
+### Added
+- **Scheduled agent execution (WP-0006, ADR-005)** — run agents on a cadence
+  against a preselected repo roster, orchestrated by activity-core and prepared
+  by kaizen-agentic (no Temporal workers or LLM runtime in this repo)
+- **`kaizen-agentic schedule`** CLI group — `init`, `validate`, `list`,
+  `prepare <agent>` (markdown/json) over `.kaizen/schedule.yml`
+- **`.kaizen/schedule.yml`** manifest + schema docs and example
+  (`docs/integrations/schedule-schema.md`, `docs/examples/.kaizen/schedule.yml`)
+- **ActivityDefinition drafts** (`enabled: false`) — `weekly-coach-orientation`,
+  `weekly-optimization-review`
+- **Design specs** — `discover_kaizen_scheduled_repos` resolver, State Hub
+  roster fields, `kaizen.schedule.prepared` event payload, activity-core handoff
+  checklist
+
+## [1.2.0] - 2026-06-16
+
+### Added
+- **`make agents-sync-package`** — sync `agents/` into packaged `data/agents/`
+- **Packaged agent parity test** — `release-check` fails when wheel data drifts from source
+- **Gitea CI flake8** — lint gate on `src/` in `.gitea/workflows/ci.yml`
+
+### Changed
+- **Install documentation** — HELLO_WORLD, CLI_CHEAT_SHEET, AGENT_DISTRIBUTION use Gitea PyPI extra index
+- **`docs/PACKAGE_RELEASE.md`** — OpenBao token custody, publish smoke-test notes, pre-tag checklist
+
+### Fixed
+- **Gitea publish workflow** — `.build-venv` for PEP 668 on haskelseed; explicit twine credentials; `tegwick` + `inter-hub-pkg-rep` token from OpenBao
+- **Helix correlation docs** — bidirectional link with agentic-resources (WP-0005 T16)
+
+## [1.1.0] - 2026-06-18
+
+### Added
+- **`kaizen-agentic feedback`** CLI and Gitea issue templates for developer feedback
+- **Gitea CI** (`.gitea/workflows/ci.yml`) — black + pytest on Python 3.10/3.12
+- **Pre-commit hooks** (`.pre-commit-config.yaml`) and `make pre-commit-install`
+- **`docs/FEEDBACK.md`** and **`docs/TELEMETRY.md`** (ADR-004 two-layer telemetry model)
+- **Ecosystem integration (WP-0004)**: Helix correlation, artifact-store publish, activity-core definitions
+- **Project metrics (WP-0003)**: ADR-004 storage, metrics CLI, optimizer wiring, tdd-workflow pilot
+- **sys-medic agent** and packaged fleet sync (20 agents in `data/agents/`)
+
+### Changed
+- **Lazy agent registry** — index by frontmatter name; parse on demand; path-based install copy
+- **CLI error messages** — clearer guidance when agents directory or package missing
+- **CONTRIBUTING.md** — post-pull reinstall instructions (`pip install -e .` / pipx)
+
+### Fixed
+- **Makefile template** in project initializer — tab characters no longer break Python linting
+- Removed stale `agents_backup_*/` scaffolding from development installs
 
 ## [1.0.1] - 2025-10-20
 

CLAUDE.md

@@ -1,5 +1,6 @@
 # kaizen-agentic — Claude Code Instructions
 
+@SCOPE.md
 @.claude/rules/repo-identity.md
 @.claude/rules/session-protocol.md
 @.claude/rules/first-session.md
@@ -7,3 +8,5 @@
 @.claude/rules/stack-and-commands.md
 @.claude/rules/architecture.md
 @.claude/rules/repo-boundary.md
+@.claude/rules/credential-routing.md
+@.claude/rules/agents.md

CONTRIBUTING.md

@@ -24,6 +24,20 @@ This document outlines how to get started, how we organise work, and how to help
 4. Verify setup: `make test-quick` or `pytest tests/`
 5. Familiarize yourself with agent system (see CLAUDE.md)
 
+**After pulling updates:** reinstall the CLI so new commands are available:
+
+```bash
+pip install -e .              # project venv
+# or
+pipx install -e . --force     # global pipx install
+```
+
+**Consumers (pip install from registry):** see [docs/PACKAGE_RELEASE.md](docs/PACKAGE_RELEASE.md)
+for Gitea PyPI credentials and `--extra-index-url` install paths.
+
+**Maintainers (release):** `make agents-sync-package` before tagging when `agents/` changes;
+`make package-check` and the pre-tag checklist in `docs/PACKAGE_RELEASE.md`.
+
 ## Development Workflow
 
 ### Project Structure
@@ -31,7 +45,7 @@ This repository follows PythonVibes best practices:
 - `src/kaizen_agentic/` - Core framework source code
 - `agents/` - Specialized agent definitions (17+ agents)
 - `tests/` - Comprehensive test suite
-- `TODO.md` - Current development tasks (Keep a Todofile format)
+- `workplans/` - Active workstreams and tasks (ADR-001)
 - `CHANGELOG.md` - Version history (Keep a Changelog format)
 
 ### Making Changes
@@ -63,6 +77,8 @@ This repository follows PythonVibes best practices:
 - **Linting**: Flake8 (`flake8 .`)
 - **Type Checking**: MyPy (`mypy src/`)
 - **Testing**: Pytest (`pytest`)
+- **Pre-commit**: `pip install pre-commit && pre-commit install` (see `.pre-commit-config.yaml`)
+- **CI**: Gitea Actions workflow `.gitea/workflows/ci.yml` runs on push/PR to `main`
 
 ### Agent Development Standards
 For contributing new agents or improving existing ones:
@@ -71,6 +87,40 @@ For contributing new agents or improving existing ones:
 - Define explicit scope and authority boundaries
 - Follow existing agent patterns in `agents/` directory
 
+#### YAML frontmatter schema
+
+```yaml
+---
+name: <agent-name>
+description: <one-line description>
+category: testing | quality | process | infrastructure | release | docs | support | meta
+memory: enabled  # optional; default enabled. Set to disabled for stateless utility agents
+---
+```
+
+#### Session-start protocol (for session-bound agents)
+
+Agents that do ongoing work across sessions should include a session-start block:
+
+1. Check for `.kaizen/agents/<name>/memory.md` in the project root
+2. If present, read it and acknowledge relevant context in the opening brief
+3. Optionally invoke `kaizen-agentic memory brief <name>` for cross-agent orientation
+
+Include this block in the agent prompt under a `## Session Start` heading.
+
+#### Session-close protocol (for session-bound agents)
+
+At the end of each session the agent should:
+
+1. Update `## Accumulated Findings`, `## What Worked`, `## Watch Points` as needed
+2. Append one line to `## Session Log` (format: `YYYY-MM-DD · <summary> · <outcome>`)
+3. Bump `last_updated` and `session_count` in the frontmatter
+
+Include this block in the agent prompt under a `## Session Close` heading.
+
+Agents for which session state is irrelevant (e.g. `keepaTodofile`, `keepaChangelog`)
+should set `memory: disabled` in their frontmatter and omit these sections.
+
 ## Types of Contributions
 
 We welcome various types of contributions:
@@ -80,6 +130,17 @@ We welcome various types of contributions:
 - **Testing**: New tests, test improvements, bug reports
 - **Performance**: Optimization improvements and measurements
 
+## Feedback
+
+We welcome bugs, feature ideas, and adoption experience reports.
+
+- **CLI:** `kaizen-agentic feedback` — lists channels and issue templates
+- **Guide:** [docs/FEEDBACK.md](docs/FEEDBACK.md)
+- **Templates:** `.gitea/ISSUE_TEMPLATE/` (bug, feature, general feedback)
+
+For cross-repo coordination between custodian agents, use State Hub messages
+(`POST /messages/`) — see session protocol in `.claude/rules/session-protocol.md`.
+
 ## Issue Reporting
 
 When reporting bugs, please include:
@@ -94,15 +155,15 @@ When reporting bugs, please include:
 1. **Discuss significant changes** in an issue first
 2. **Keep PRs focused** on a single feature or fix
 3. **Write clear commit messages** following conventional commit format
-4. **Update relevant documentation** including TODO.md and CHANGELOG.md
+4. **Update relevant documentation** including workplans and CHANGELOG.md
 5. **Ensure all checks pass** including tests and linting
 6. **Respond to review feedback** promptly and constructively
 
 ## Agent-Assisted Development
 
 This repository includes 17+ specialized agents to assist with development:
-- Use `todo-keeper` for TODO.md maintenance
-- Use `changelog-keeper` for CHANGELOG.md updates
+- Use `keepaChangelog` for CHANGELOG.md updates
+- Use `project-assistant` for workplan and session orientation
 - Use `contributing-keeper` for this file maintenance
 - See CLAUDE.md for complete agent catalog and usage
 

INTENT.md

@@ -0,0 +1,85 @@
+# INTENT
+
+## Purpose
+
+This repository exists to define and evolve **KaizenAgentic**: a framework and product concept for turning AI coding agents from static tools into continuously improving digital talents.
+
+KaizenAgentic applies the principle of kaizen — continuous improvement through small, measurable, compounding refinements — to agent design, coding workflows, codebase quality, and agent optimization. It provides the concepts, templates, guidance, and business framing needed to build agents that can be observed, evaluated, refined, and improved over time.
+
+## Primary Utility
+
+The primary utility of this repository is to serve as the conceptual and operational seed for a **digital talent agency for AI coding agents**.
+
+It should help define:
+
+* how Kaizen agents are specified,
+* how their performance is measured,
+* how agent behavior is improved through feedback loops,
+* how codebase improvement guidance can be made human-readable, machine-checkable, and agent-executable,
+* how reusable capabilities, prompt practices, and improvement programs compound into better software development workflows.
+
+## Intended Users
+
+This repository is intended for:
+
+* builders of AI coding agents,
+* developers using Claude, Cursor, or similar coding assistant environments,
+* teams that want coding agents to improve with real-world use,
+* maintainers who want code quality guidance that can be checked, refactored, tested, and measured,
+* product and business designers shaping KaizenAgentic as a service or platform.
+
+## Strategic Role in the System
+
+KaizenAgentic plays the role of a **meta-improvement layer** for agentic software development.
+
+It is not merely a collection of prompts or coding assistants. It defines a system in which agents become measurable, versioned, testable, and optimizable units of digital work. Subagents perform specific tasks, while optimization logic observes their performance and proposes evidence-based refinements.
+
+The repository should become the place where the core language, principles, templates, and operating model for this improvement loop are stabilized.
+
+## Strategic Boundaries
+
+This repository should own:
+
+* the KaizenAgentic mission and conceptual model,
+* the KaizenAgent definition template,
+* the meta-optimizer concept,
+* guidance for measurable and idempotent agent behavior,
+* the codebase improvement guidance model,
+* the relationship between prompts, experiments, mantras, agents, and reusable capabilities,
+* the initial product, pricing, revenue, and brand framing.
+
+This repository should not own:
+
+* all concrete implementations of individual agents,
+* customer-specific agent configurations,
+* vendor-specific integrations beyond reference patterns,
+* the complete runtime platform for executing agents,
+* unrelated generic AI automation concepts that do not contribute to measurable continuous improvement,
+* codebase-specific gameplans except as examples or templates.
+
+## Design Principles
+
+* **Continuous Improvement**: Every agent, guide, and workflow should be designed to improve through repeated use.
+* **Measurable by Default**: Success criteria, metrics, and before/after deltas should be part of every meaningful agent or guidance definition.
+* **Idempotent Operations**: Agent actions should converge toward desired states and remain safe to repeat.
+* **Evidence over Intuition**: Improvements should be based on observed performance, tests, metrics, and explicit feedback.
+* **Separation of Concerns**: Task-specific agents, measurement logic, optimization logic, and business framing should remain distinguishable.
+* **Composable Capabilities**: Reusable units should package intent, interfaces, knowledge, and operational behavior, not just code.
+* **Human-Readable and Machine-Executable**: Guidance should be understandable by humans while also being checkable by tools and executable by agents.
+* **Rollback-Ready Evolution**: Agent specifications and improvements should be versioned, testable, and reversible.
+* **Compounding Value**: Small, durable improvements should accumulate into stronger agents, cleaner codebases, and better development workflows.
+
+## Maturity Target
+
+The repository should mature into the canonical reference for the KaizenAgentic operating model.
+
+At maturity, it should provide enough structure for a team to define, deploy, measure, refine, and commercialize AI coding agents as continuously improving digital talents. It should support both practical implementation and strategic communication: useful to developers, agent designers, product owners, and early customers.
+
+## Stability Note
+
+`INTENT.md` describes the stable purpose and strategic role of the repository.
+
+Changes to this file should represent a deliberate shift in what KaizenAgentic is meant to become, not ordinary scope evolution. Concrete implementation plans, product details, agent specifications, and experiments should live in PRDs, gameplans, templates, guidance documents, or implementation repositories.
+
+
+xxx

Makefile

@@ -1,11 +1,14 @@
 # Makefile for Kaizen Agentic development tasks
 
-.PHONY: help setup-complete setup-structure setup-python setup-tools setup-docs setup-tests setup-verify ensure-project-structure install-dev install-local install-global standards-check standards-fix standards-test test test-all build clean lint format venv-status agents-list agents-update agents-validate agents-status agents-install-cli release-check release-prepare release-test release-publish release-finalize release-rollback
+.PHONY: help setup-complete setup-structure setup-python setup-tools setup-docs setup-tests setup-verify ensure-project-structure install-dev install-local install-global standards-check standards-fix standards-test test test-all build clean lint format venv-status agents-list agents-update agents-validate agents-status agents-sync-package agents-install-cli release-check release-prepare release-test release-publish publish-gitea package-check release-finalize release-rollback
 
 # Variables
 VENV = .venv
 VENV_PYTHON = $(VENV)/bin/python
 VENV_PIP = $(VENV)/bin/pip
+GITEA_PACKAGE_OWNER ?= coulomb
+GITEA_PYPI_REPOSITORY_URL ?= https://gitea.coulomb.social/api/packages/$(GITEA_PACKAGE_OWNER)/pypi
+GITEA_PYPI_SIMPLE_URL ?= https://gitea.coulomb.social/api/packages/$(GITEA_PACKAGE_OWNER)/pypi/simple/
 
 # Default target
 help:
@@ -38,13 +41,16 @@ help:
 	@echo "  agents-update   - Update agents to latest versions"
 	@echo "  agents-validate - Validate agent definitions"
 	@echo "  agents-status   - Show agent status and project info"
+	@echo "  agents-sync-package - Sync agents/ into packaged data/agents/ (DRY_RUN=1 to preview)"
 	@echo "  agents-install-cli - Install kaizen-agentic CLI tool"
 	@echo ""
 	@echo "Release Management:"
 	@echo "  release-check   - Validate release readiness (tests, linting, version consistency)"
 	@echo "  release-prepare - Prepare release (update versions, build packages)"
+	@echo "  package-check   - Build and validate wheel/sdist with twine"
+	@echo "  publish-gitea   - Publish dist/* to Coulomb Gitea PyPI registry"
 	@echo "  release-test    - Test publication workflow using TestPyPI"
-	@echo "  release-publish - Publish to production PyPI"
+	@echo "  release-publish - Publish to production PyPI (pypi.org)"
 	@echo "  release-finalize - Post-release tasks (tags, GitHub release, documentation)"
 	@echo "  release-rollback - Emergency rollback procedures"
 	@echo ""
@@ -567,11 +573,19 @@ format: $(VENV)/bin/activate
 clean:
 	@echo "🧹 Cleaning build artifacts and cache..."
 	@rm -rf build/ dist/ *.egg-info/ .pytest_cache/ __pycache__/ .coverage htmlcov/
+	@rm -rf agents_backup_*/
 	@find . -type d -name "__pycache__" -exec rm -rf {} + 2>/dev/null || true
 	@find . -type f -name "*.pyc" -delete 2>/dev/null || true
 	@find . -type f -name "*.pyo" -delete 2>/dev/null || true
 	@echo "✅ Cleanup completed"
 
+# Install pre-commit hooks (WP-0001 T02)
+pre-commit-install: $(VENV)/bin/activate
+	@echo "🔧 Installing pre-commit hooks..."
+	@$(VENV_PIP) install pre-commit
+	@$(VENV)/bin/pre-commit install
+	@echo "✅ pre-commit installed — run 'pre-commit run --all-files' to verify"
+
 # ============================================================================
 # Standards Compliance Targets
 # ============================================================================
@@ -798,7 +812,9 @@ agents-update: $(VENV)/bin/activate
 	@if command -v kaizen-agentic >/dev/null 2>&1; then \
 		kaizen-agentic update; \
 	else \
-		echo "⚠️  kaizen-agentic CLI not found. Install with: pip install kaizen-agentic"; \
+		echo "⚠️  kaizen-agentic CLI not found."; \
+		echo "   Dev install: make agents-install-cli  (or pip install -e .)"; \
+		echo "   Registry: see docs/PACKAGE_RELEASE.md"; \
 	fi
 
 # Validate installed agents
@@ -807,7 +823,9 @@ agents-validate:
 	@if command -v kaizen-agentic >/dev/null 2>&1; then \
 		kaizen-agentic validate; \
 	else \
-		echo "⚠️  kaizen-agentic CLI not found. Install with: pip install kaizen-agentic"; \
+		echo "⚠️  kaizen-agentic CLI not found."; \
+		echo "   Dev install: make agents-install-cli  (or pip install -e .)"; \
+		echo "   Registry: see docs/PACKAGE_RELEASE.md"; \
 	fi
 
 # Show agent status and project information
@@ -816,7 +834,9 @@ agents-status:
 	@if command -v kaizen-agentic >/dev/null 2>&1; then \
 		kaizen-agentic status; \
 	else \
-		echo "⚠️  kaizen-agentic CLI not found. Install with: pip install kaizen-agentic"; \
+		echo "⚠️  kaizen-agentic CLI not found."; \
+		echo "   Dev install: make agents-install-cli  (or pip install -e .)"; \
+		echo "   Registry: see docs/PACKAGE_RELEASE.md"; \
 		echo ""; \
 		echo "Manual agent check:"; \
 		if [ -d "agents" ]; then \
@@ -826,6 +846,34 @@ agents-status:
 		fi; \
 	fi
 
+# Sync canonical agents/ into packaged wheel data
+AGENTS_SRC_DIR = agents
+AGENTS_PKG_DIR = src/kaizen_agentic/data/agents
+
+agents-sync-package:
+	@echo "📦 Syncing packaged agents from $(AGENTS_SRC_DIR)/ ..."
+	@mkdir -p $(AGENTS_PKG_DIR); \
+	SYNCED=0; \
+	for f in $(AGENTS_SRC_DIR)/agent-*.md; do \
+		dest="$(AGENTS_PKG_DIR)/$$(basename $$f)"; \
+		if [ -n "$(DRY_RUN)" ]; then \
+			if [ -f "$$dest" ] && cmp -s "$$f" "$$dest"; then \
+				echo "  = $$(basename $$f) (unchanged)"; \
+			else \
+				echo "  → $$(basename $$f)"; \
+			fi; \
+		else \
+			cp "$$f" "$$dest"; \
+			echo "  ✓ $$(basename $$f)"; \
+			SYNCED=$$((SYNCED + 1)); \
+		fi; \
+	done; \
+	if [ -z "$(DRY_RUN)" ]; then \
+		echo "✅ Synced $$SYNCED file(s) to $(AGENTS_PKG_DIR)/"; \
+	else \
+		echo "ℹ️  DRY_RUN preview only — no files copied"; \
+	fi
+
 # Install agent distribution CLI
 agents-install-cli: $(VENV)/bin/activate
 	@echo "📦 Installing Kaizen Agentic CLI..."
@@ -882,6 +930,21 @@ release-check: $(VENV)/bin/activate
 		echo "    ❌ Build system not configured"; \
 		ISSUES=$$((ISSUES + 1)); \
 	fi; \
+	echo "  • Packaged Agent Parity:"; \
+	PARITY_OK=1; \
+	for f in agents/agent-*.md; do \
+		dest="src/kaizen_agentic/data/agents/$$(basename $$f)"; \
+		if [ ! -f "$$dest" ] || ! cmp -s "$$f" "$$dest"; then \
+			PARITY_OK=0; \
+			break; \
+		fi; \
+	done; \
+	if [ $$PARITY_OK -eq 1 ] && ls agents/agent-*.md >/dev/null 2>&1; then \
+		echo "    ✅ agents/ matches data/agents/"; \
+	else \
+		echo "    ❌ Packaged agents drift from agents/ — run: make agents-sync-package"; \
+		ISSUES=$$((ISSUES + 1)); \
+	fi; \
 	echo ""; \
 	if [ $$ISSUES -eq 0 ]; then \
 		echo "✅ Release readiness: PASSED"; \
@@ -907,8 +970,24 @@ release-prepare: release-check clean
 	ls -la dist/ | grep "$$VERSION" || echo "   • Package files:"; ls -la dist/; \
 	echo ""; \
 	echo "💡 Next steps:"; \
-	echo "   • Run 'make release-test' to test publication"; \
-	echo "   • Run 'make release-publish' for production release"
+	echo "   • Run 'make publish-gitea' for Coulomb Gitea PyPI"; \
+	echo "   • Run 'make release-test' to test publication on TestPyPI"; \
+	echo "   • Run 'make release-publish' for pypi.org (when configured)"
+
+# Build and validate distributions
+package-check: release-prepare
+	$(VENV_PYTHON) -c "import twine" 2>/dev/null || $(VENV_PIP) install twine
+	$(VENV_PYTHON) -m twine check dist/*
+
+# Publish to Coulomb Gitea PyPI registry
+publish-gitea: package-check
+ifndef TWINE_USERNAME
+	$(error TWINE_USERNAME is required (e.g. export TWINE_USERNAME=<gitea-user>))
+endif
+ifndef TWINE_PASSWORD
+	$(error TWINE_PASSWORD is required (e.g. export TWINE_PASSWORD=$$GITEA_API_TOKEN))
+endif
+	$(VENV_PYTHON) -m twine upload --repository-url "$(GITEA_PYPI_REPOSITORY_URL)" dist/*
 
 # Test publication workflow using TestPyPI
 release-test: release-prepare
@@ -980,7 +1059,8 @@ release-finalize: $(VENV)/bin/activate
 	echo ""; \
 	echo "  • Documentation:"; \
 	echo "    💡 Verify installation instructions work:"; \
-	echo "       pip install kaizen-agentic==$$VERSION"; \
+	echo "       pip install kaizen-agentic==$$VERSION --extra-index-url <gitea-pypi-simple>"; \
+	echo "       See docs/PACKAGE_RELEASE.md"; \
 	echo ""; \
 	echo "✅ Release finalization checklist provided"; \
 	echo "   Complete manual steps above to finish release process"
@@ -1018,4 +1098,4 @@ release-rollback: $(VENV)/bin/activate
 	echo "   • Always test with TestPyPI first"; \
 	echo "   • Use staging/preview environments"; \
 	echo "   • Implement automated quality gates"; \
-	echo "   • Consider pre-release versions for testing"
+	echo "   • Consider pre-release versions for testing"

README.md

@@ -1,8 +1,10 @@
 # Kaizen Agentic
 
-AI agent development framework embracing continuous improvement through specialized agents and comprehensive development workflows.
+AI **agency** framework: 18 specialized agents that arrive in your project informed, learn from experience, and improve over time.
 
-This project embraces the Japanese concept of "kaizen" (continuous improvement) applied to AI agent development. Every coding subagent becomes part of an optimization loop where performance is measured, patterns are analyzed, and specifications are refined over time.
+kaizen-agentic provides two things: a library of agent instruction sets you deploy into projects, and an **agency framework** that gives those agents persistent memory and coordination. Agents accumulate project-scoped knowledge across sessions. A Coach meta-agent synthesises patterns across the entire fleet and briefs incoming agents on what to know first.
+
+This project embraces the Japanese concept of "kaizen" (continuous improvement) applied to AI agent development. Every agent becomes part of an optimization loop where performance is measured, patterns are analyzed, and knowledge is carried forward.
 
 ## Quick Start
 
@@ -35,13 +37,21 @@ python3 -m build && make install-local
 source .venv/bin/activate  # Required for each session
 ```
 
-**From PyPI (Coming Soon):**
+**From Gitea PyPI (v1.1.0+):**
 ```bash
-pip install kaizen-agentic  # Available after v1.0.0 publication
-# or
-pipx install kaizen-agentic  # Recommended for global CLI tools
+export GITEA_PACKAGE_USER=<gitea-user>
+export GITEA_PACKAGE_TOKEN=<package-token>
+
+pip install kaizen-agentic \
+  --extra-index-url "https://${GITEA_PACKAGE_USER}:${GITEA_PACKAGE_TOKEN}@gitea.coulomb.social/api/packages/coulomb/pypi/simple/"
+
+# or global CLI via pipx
+pipx install kaizen-agentic \
+  --pip-args="--extra-index-url https://${GITEA_PACKAGE_USER}:${GITEA_PACKAGE_TOKEN}@gitea.coulomb.social/api/packages/coulomb/pypi/simple/"
 ```
 
+See [docs/PACKAGE_RELEASE.md](docs/PACKAGE_RELEASE.md) for release and CI details.
+
 ### Your First Project (New Users)
 **👋 New to Kaizen Agentic?** Follow our [Hello World Tutorial](docs/HELLO_WORLD_TUTORIAL.md) for a complete step-by-step guide.
 
@@ -70,14 +80,46 @@ kaizen-agentic install keepaTodofile keepaChangelog tdd-workflow
 kaizen-agentic status
 ```
 
+## Agency Framework
+
+Agents deployed into a project can accumulate **project-scoped memory** — a structured file written at session close and read at session start. A **Coach** meta-agent reads across all agent memories and produces targeted orientation briefs for incoming agents.
+
+```bash
+# Scaffold memory for an agent
+kaizen-agentic memory init sys-medic
+
+# Brief an incoming agent using all existing project memories
+kaizen-agentic memory brief tdd-workflow
+
+# Review an agent's accumulated knowledge
+kaizen-agentic memory show project-management
+```
+
+See [docs/agency-framework.md](docs/agency-framework.md) for the full model.
+
+## Orientation
+
+Read in this order for strategic context:
+
+1. [INTENT.md](INTENT.md) — purpose, boundaries, design principles
+2. [wiki/KaizenAgenticMission.md](wiki/KaizenAgenticMission.md) — product narrative
+3. [wiki/AboutKaizenAgents.md](wiki/AboutKaizenAgents.md) — agent concepts and metrics pilot
+4. [wiki/EcosystemIntegration.md](wiki/EcosystemIntegration.md) — ecosystem composition
+5. [SCOPE.md](SCOPE.md) — repository boundaries and current state
+6. [history/](history/) — persisted assessments and gap analyses
+
+Released **v1.1.0** — see [CHANGELOG.md](CHANGELOG.md). Workplans: WP-0001 through WP-0004 completed.
+
+Feedback: `kaizen-agentic feedback` · [docs/FEEDBACK.md](docs/FEEDBACK.md)
+
 ## Features
 
-- **16+ Specialized Agents**: Project management, testing, code quality, documentation
-- **CLI Tool**: Easy agent installation and management (`kaizen-agentic`)
+- **20 Specialized Agents**: Project management, testing, code quality, infrastructure, meta
+- **Agency Framework**: Project-scoped agent memory + Coach meta-agent for cross-agent synthesis
+- **CLI Tool**: Easy agent installation, management, and memory commands (`kaizen-agentic`)
 - **Project Templates**: Pre-configured setups for different project types
 - **Claude Code Integration**: Seamless integration with Claude Code workflows
 - **Comprehensive Testing**: Full test coverage with multiple testing strategies
-- **Standards Compliance**: Follows PythonVibes and industry best practices
 
 ## Available Agents
 
@@ -101,6 +143,10 @@ kaizen-agentic status
 - **setupRepository**: Repository initialization and standards compliance
 - **claude-documentation**: Claude Code configuration and documentation
 - **tooling-optimization**: Repository tooling usage optimization
+- **sys-medic**: Infrastructure health monitoring and diagnostics
+
+### Meta
+- **coach**: Coaching meta-agent — reads all project agent memories, synthesises cross-agent briefs, and orients incoming agents
 
 [View complete agent list](docs/AGENT_DISTRIBUTION.md#agent-categories)
 
@@ -124,4 +170,4 @@ kaizen-agentic templates
 The CLI currently implements a workaround for spurious error messages in the Click library. This affects the `install` command but is transparent to users. See [CLICK_WORKAROUND.md](CLICK_WORKAROUND.md) for technical details and removal timeline.
 
 **User Impact**: None - the workaround provides clean CLI output
-**Status**: Monitoring Click library updates for resolution
+**Status**: Monitoring Click library updates for resolution

SCOPE.md

@@ -3,92 +3,165 @@
 > This file helps you quickly understand what this repository is about,
 > when it is relevant, and when it is not.
 > It is intentionally lightweight and may be incomplete.
+> For strategic purpose and boundaries, see `INTENT.md`.
 
 ---
 
 ## One-liner
 
-AI agent development framework providing specialized agent personas (markdown instruction sets) and CLI scaffolding tools for embedding domain expertise into Claude Code sessions.
+KaizenAgentic: a digital talent agency framework — agent personas, project memory, measurable improvement loops, and CLI tooling for deploying continuously refining AI coding agents into Claude Code sessions.
 
 ---
 
 ## Core Idea
 
-Kaizen-agentic makes recurring development workflows (TDD, refactoring, project management, documentation) first-class by packaging them as named agent personas. You invoke an agent by name, load its instruction set, and follow it — the agent defines the workflow, Claude Code executes it. The "kaizen" (continuous improvement) philosophy means agents are refined based on performance over time.
+This repo is the canonical home for the **KaizenAgentic** operating model (`INTENT.md`, `wiki/`). It packages recurring development workflows as named agent personas invoked in Claude Code. The **agency layer** adds project-scoped memory (`.kaizen/agents/<name>/memory.md`) and a **Coach** meta-agent for cross-agent orientation. The **kaizen loop** — measure, analyse, refine — is defined in `wiki/` and partially implemented: `OptimizationLoop` exists in Python, but per-execution metrics collection and optimizer integration are in progress (WP-0003). Runtime execution remains Claude Code's responsibility.
 
 ---
 
 ## In Scope
 
-- 17+ agent definition files (`agents/agent-*.md`) — markdown persona instruction sets
-- Agent categories: testing, quality, process, infrastructure, release, documentation
-- CLI tooling: `kaizen-agentic init/install/status` for project scaffolding
-- Project templates (python-basic, python-web, python-cli, python-data, comprehensive)
-- Python framework: `Agent` base class, `AgentConfig` dataclass, `OptimizationLoop` for performance tracking
-- Custodian MCP integration: `list_kaizen_agents()` and `get_kaizen_agent()` tools
+- **Strategic framing**: `INTENT.md` (purpose, boundaries, design principles) and `wiki/` (mission, agent template, guidance model, brand/pricing)
+- **20 agent definitions** (`agents/agent-*.md`) — markdown persona instruction sets with YAML frontmatter (reference fleet; see `INTENT.md` boundaries)
+- **Agent categories**: project-management, development-process, code-quality, infrastructure, testing, documentation, meta
+- **Agency framework**: project memory convention (ADR-002), session-start/close protocols, Coach meta-agent (`agent-coach.md`)
+- **Protocol runbooks** (`agents/protocols/<agent>/<slug>.md`) — procedural checklists distinct from agent prompts
+- **CLI tooling** (`kaizen-agentic`): `init`, `install`, `update`, `remove`, `list`, `status`, `validate`, `templates`, `detect`, `migrate`, `extensions`, `memory` (show/init/brief/clear), `protocols` (list/show); `metrics` commands planned in WP-0003
+- **Project templates** (python-basic, python-web, python-cli, python-data, comprehensive) — agent bundles in registry code
+- **Python framework** (`src/kaizen_agentic/`): `Agent`/`AgentConfig`, `AgentRegistry`, `AgentInstaller`, `OptimizationLoop`/`PerformanceMetrics`, detection/migration/extensions
+- **Packaged agent data** (`src/kaizen_agentic/data/agents/`) — agents bundled for pip installs (sync with `agents/` via `make agents-update`)
+- **Gitea PyPI publication** — `make publish-gitea`, tag-triggered `.gitea/workflows/publish-python-package.yml` (v1.1.0+)
+- **Custodian MCP integration** (owned by `the-custodian`): `list_kaizen_agents()` and `get_kaizen_agent()`
+- **ADRs and workplans** for memory, protocols, workplan, and metrics conventions
 
 ---
 
 ## Out of Scope
 
-- Agent runtime / execution engine (agents are persona definitions; execution is Claude Code's responsibility)
-- LLM orchestration or multi-agent debate systems
-- Project-specific implementation (agents guide; they do not build the software)
-- Commercial features or PyPI distribution (pre-v1.0)
+- Agent runtime / execution engine (agents are persona definitions; Claude Code executes them)
+- LLM orchestration, scheduling, or multi-agent debate systems
+- Project-specific implementation (agents guide work; they do not build the target software)
+- Custodian State Hub, MCP server code, or cross-domain governance (consumed, not owned)
+- Full KaizenGuidance codemod pipeline (vision in `wiki/KaizenGuidance.md`; not yet implemented)
+- Public pypi.org distribution (optional; Coulomb Gitea registry is primary)
 
 ---
 
 ## Relevant When
 
-- Starting a guided development workflow (TDD, refactoring, testing, requirements)
-- Scaffolding a new project with consistent structure and best-practice tooling
-- Looking up what specialized agent personas are available for a domain session
-- Contributing a new agent persona to the ecosystem
+- Understanding **why** KaizenAgentic exists and what it must not become (`INTENT.md`)
+- Exploring the conceptual model: agent template, optimizer, guidance, composable capabilities (`wiki/`)
+- Starting a guided development workflow (TDD, refactoring, testing, requirements, scope analysis)
+- Deploying agents with persistent cross-session memory or Coach-mediated orientation
+- Scaffolding projects with agent bundles; looking up personas via CLI or Custodian MCP
+- Contributing agent personas, protocol runbooks, or improvement-loop conventions
 
 ---
 
 ## Not Relevant When
 
-- Ad-hoc, one-off scripting with no need for structured guidance
-- Non-Claude-Code development environments
-- Need for runtime orchestration or scheduling (not a scheduler)
+- Ad-hoc scripting with no need for structured agent guidance
+- Non-Claude-Code development environments (primary target; patterns may transfer)
+- Need for runtime orchestration, task scheduling, or autonomous agent execution
+- Repository capability profiling or SCOPE.md generation at scale (see `repo-scoping`)
 
 ---
 
 ## Current State
 
-- Status: experimental → stabilizing (v1.0.2 released)
-- Implementation: ~85% — 17 agents defined, CLI functional, templates working; optimization loop pattern established but not exercised at scale
-- Stability: stable CLI and agent loading
-- Usage: installed in dev projects; agents callable via Custodian MCP hub-wide
+- Status: stabilizing (v1.1.0 published on Gitea PyPI; WP-0001–0004 completed)
+- Strategic layer: `INTENT.md` and `wiki/` established; ecosystem integration docs in `wiki/EcosystemIntegration.md`
+- Implementation: 20 agents, full CLI (`metrics`, `memory`, `feedback`), agency memory + ADR-004 metrics + optimizer wiring
+- Stability: CLI stable (Click workaround in place); Gitea CI on main; publish workflow on `v*` tags
+- Usage: internal dev projects and Custodian MCP hub-wide; pip install via Gitea extra index
+- Active work: **WP-0006** (scheduled agent execution via activity-core → v1.3.0)
 
 ---
 
 ## How It Fits
 
-- Upstream dependencies: Claude Code (agent invocation), kaizen philosophy
-- Downstream consumers: Custodian State Hub (loads agents via MCP); all six domains (teams use agents for guided workflows)
-- Often used with: the-custodian (MCP integration), markitect_project (project-management agent), activity-core (scaffolding)
+- Upstream dependencies: Claude Code (agent invocation), kaizen continuous-improvement philosophy
+- Downstream consumers: Custodian State Hub (MCP agent discovery); domain repos that install agents and maintain `.kaizen/` state
+- Often used with: `the-custodian` (MCP integration), `markitect_project` (project-management patterns), `activity-core` (scaffolding references), `repo-scoping` (SCOPE.md generation)
 
 ---
 
 ## Terminology
 
-- Preferred terms: agent, agent persona, AgentConfig, project template
-- Also known as: "kaizen agents", "the agent library"
-- Potentially confusing terms: "Agent" here is a persona/instruction set, not a running process
+- Preferred terms: KaizenAgentic (product), agent, agent persona, agency, project memory, protocol runbook, Coach, kaizen loop
+- Also known as: "kaizen agents", "kaizen-agentic" (repo/package slug), "the agent library"
+- Potentially confusing terms: "Agent" is a persona/instruction set, not a running process; "agency" means memory + coaching, not autonomous orchestration; repo slug `kaizen-agentic` vs product name `KaizenAgentic`
 
 ---
 
 ## Related / Overlapping Repositories
 
-- `the-custodian` — hosts MCP tools that load agents; custodian agent copies live in `the-custodian/agents/`
+- `the-custodian` — hosts MCP tools that load agents; integration code lives there, not here
+- `repo-scoping` — generates/refreshes SCOPE.md from approved characteristics
 - `markitect_project` — references kaizen-agentic as a capability submodule
+- `sys-medic` (source repo) — origin of sys-medic agent; canonical copy in `agents/agent-sys-medic.md`
 
 ---
 
 ## Getting Oriented
 
-- Start with: `README.md` (quick start, agent list, installation)
-- Key files / directories: `agents/` (all persona definitions), `src/kaizen_agentic/` (Python framework), `templates/` (project scaffolds)
-- Entry points: `kaizen-agentic --help`; or via MCP: `get_kaizen_agent("scope-analyst")`
+Read in this order for full context:
+
+1. `INTENT.md` — stable purpose, boundaries, design principles
+2. `wiki/KaizenAgenticMission.md` — product narrative and key components
+3. `wiki/EcosystemIntegration.md` — how KaizenAgentic composes with adjacent repos
+4. `wiki/KaizenAgentTemplate.md` — intended agent specification format
+5. `README.md` — quick start and agency overview
+6. `docs/agency-framework.md` — memory, coach, protocols, metrics (ADR-004)
+7. `history/` — persisted assessments and gap analyses
+8. `workplans/` — active implementation roadmap
+
+Key directories: `wiki/` (conceptual model), `agents/` (personas), `agents/protocols/` (runbooks), `src/kaizen_agentic/` (Python framework), `docs/adr/` (conventions)
+
+Entry points: `kaizen-agentic --help`; MCP: `get_kaizen_agent("scope-analyst")`; docs: `docs/GETTING_STARTED.md`, `docs/AGENT_DISTRIBUTION.md`
+
+---
+
+## Provided Capabilities
+
+```capability
+type: process
+title: Guided development agent personas
+description: Named markdown instruction sets for TDD, refactoring, documentation standards, requirements engineering, and project management workflows in Claude Code sessions.
+keywords: [agents, personas, tdd, refactoring, claude-code, workflows]
+```
+
+```capability
+type: infrastructure
+title: Agent deployment and project scaffolding CLI
+description: Install, update, validate, and bundle agents into new or existing projects via the kaizen-agentic CLI and registry-backed templates.
+keywords: [cli, install, templates, scaffolding, registry]
+```
+
+```capability
+type: process
+title: Project-scoped agent memory and coaching
+description: Convention and CLI for .kaizen/agents memory files, session protocols, and Coach-mediated orientation briefs across a deployed agent fleet.
+keywords: [memory, coach, agency, kaizen, cross-session]
+```
+
+```capability
+type: infrastructure
+title: Kaizen agent discovery via Custodian MCP
+description: Single source of truth for agent definitions consumed by the Custodian State Hub list_kaizen_agents and get_kaizen_agent tools.
+keywords: [mcp, custodian, discovery, agent-library]
+```
+
+```capability
+type: process
+title: KaizenAgentic conceptual model and agent specification standards
+description: Strategic framing, design principles, agent template, optimizer spec, and improvement philosophy via INTENT.md and wiki/.
+keywords: [kaizen, intent, template, optimization, digital-talent-agency]
+```
+
+---
+
+## Notes
+
+- `agents/` (20 files) is the development source of truth; `src/kaizen_agentic/data/agents/` must stay in sync (enforced in WP-0005 T09–T10)
+- Agent definitions use minimal frontmatter today; full `wiki/KaizenAgentTemplate.md` conformance is a maturity target, not current reality

TODO.md

@@ -1,228 +0,0 @@
-# Todofile
-
-This is a "to do next" file, particularly useful to keep the human and a coding assistant in sync.
-
-The format is based on [Keep a Todofile V0.0.1](https://coulomb.social/open/TodoFileGuide).
-
-The structure organizes **future tasks** by their impact, just as a changelog organizes past changes by their impact.
-
-***
-
-## [Unreleased] - *Active Vibe-Coding State* 💡
-
-Tasks moved to workplan: `workplans/kaizen-agentic-WP-0001-community-engagement.md`
-Hub workstream: `kaizen-wp-0001-community-engagement` (8 tasks, all todo)
-
-***
-
-## [1.1.0] - Community Engagement and Advanced Automation - *Next Planned Increment*
-
-This version focuses on community engagement, advanced automation, and enhanced user experience.
-
-### To Add
-* **Developer feedback mechanisms** for easy collection of user feedback and suggestions
-* **Interactive agent selection** wizard for new projects
-* **GitHub Actions workflows** for CI/CD automation
-* **Agent metrics and telemetry** system for usage tracking and optimization
-* **Agent template validation** system with schema enforcement
-* **Documentation generation** automation from agent metadata
-* **Community contribution guidelines** and contributor onboarding
-
-### To Refactor
-* **CLI error handling** with more user-friendly messages and suggestions
-* **Performance optimization** for handling large numbers of agents
-* **Installation process** with progress indicators and detailed feedback
-
-### To Fix
-* **Cross-platform compatibility** testing and fixes for Windows/macOS environments
-* **Edge case handling** in dependency resolution algorithms
-* **Memory usage optimization** for large-scale agent installations
-
-### To Secure
-* **Agent integrity verification** with checksums and validation
-* **Sandboxed agent execution** for security-sensitive environments
-* **Configuration file validation** to prevent malicious modifications
-
-### To Remove
-* **Legacy installation methods** that are no longer supported
-* **Deprecated CLI options** and maintain backward compatibility warnings
-
-***
-
-## [COMPLETED] - *Documentation Standards Compliance - Version 0.2.0*
-
-### ✅ Completed: To Add
-* **CLI interface** for agent management and execution - DONE
-  - Full `kaizen-agentic` CLI with 8 commands (init, install, update, remove, list, status, validate, templates)
-  - Console script entry point for global availability
-  - Complete command-line interface with options and help
-* **Comprehensive tests** for optimization module (PerformanceMetrics, OptimizationLoop) - DONE
-  - 24 tests covering all components with 100% pass rate
-  - Test coverage for registry, installer, and core functionality
-  - Automated test execution with make test/test-all targets
-* **Agent registry and installer functionality** - DONE
-  - Complete AgentRegistry with categorization and dependency resolution
-  - AgentInstaller with backup/rollback capabilities
-  - ProjectInitializer with template-based project creation
-* **Comprehensive documentation system** - DONE
-  - GETTING_STARTED.md - Complete setup and usage guide
-  - AGENT_DISTRIBUTION.md - Architecture documentation
-  - CLI_CHEAT_SHEET.md - Quick reference guide
-  - Updated README.md with complete usage examples
-
-### ✅ Completed: To Refactor
-* **Agent definitions** to follow consistent format standards - DONE
-  - All 17+ agents updated to YAML frontmatter format
-  - Consistent categorization system (project-management, development-process, etc.)
-  - Proper dependency declarations and descriptions
-* **Makefile structure** for better user experience - DONE
-  - Reorganized with consistent naming (agents-, setup-, standards- prefixes)
-  - Enhanced help system with examples and clear descriptions
-  - 50+ targets organized into logical sections
-* **Test execution performance** optimization - DONE
-  - Fast execution with all 24 tests completing in <1 second
-  - Parallel execution capabilities
-  - Efficient backup/cleanup in test teardown
-
-### ✅ Completed: To Fix
-* **Makefile targets** compatibility across environments - DONE
-  - Cross-platform compatibility with proper shell detection
-  - Virtual environment handling with fallback mechanisms
-  - Error handling and recovery in setup processes
-* **Linting issues** in core modules - DONE
-  - All flake8 violations resolved across entire codebase
-  - PEP 8 compliance achieved
-  - Consistent code formatting with black
-* **Virtual environment setup** reliability - DONE
-  - Robust venv creation and activation
-  - Dependency installation with upgrade handling
-  - Status checking and validation
-* **CLI installation make target (agents-install-cli)** - DONE
-  - Target is working properly and requires virtual environment activation as documented
-  - Installation process functions correctly with proper venv setup
-* **YAML frontmatter errors in agent files** causing loading failures - DONE
-  - All 16 agents now properly loading without YAML parsing errors
-  - Frontmatter format standardized across all agent definitions
-* **Agent categorization issues** (agents showing as "Unknown" instead of proper categories) - DONE
-  - All 16 agents now properly categorized and displaying correct categories
-  - Category mapping and recognition system functioning correctly
-
-### ✅ Completed: To Secure
-* **Configuration file validation** - DONE
-  - Safe YAML parsing with error handling
-  - Input validation for all CLI parameters
-  - Backup creation before modifications
-* **Agent integrity checks** - DONE
-  - Validation system for agent definitions
-  - Dependency conflict detection
-  - Installation verification
-
-### ✅ Completed: To Remove
-* **Obsolete test fixtures** - DONE
-  - Clean test directory structure
-  - Removed unused imports and variables
-  - Eliminated development scaffolding
-
-***
-
-## [COMPLETED] - *Scenario 1: Greenfield Project Excellence - Version 0.2.1*
-
-### ✅ Completed: Scenario 1 Tasks
-* **Scenario 1 exploration: Establish codebase from scratch** - DONE
-  - Research current onboarding experience with existing setup targets - DONE
-  - Identify gaps in documentation for new project creation - DONE
-  - Test and validate smooth project initialization workflows - DONE
-  - Evaluate agent selection and recommendation systems for new projects - DONE
-  - Document best practices for greenfield project setup - DONE
-
-### ✅ Completed: Additional Scenario 1 Improvements
-* **Agent template name mappings fixed** - DONE
-  - Fixed agent template name mappings to match actual agent names
-  - Ensured consistency between template references and installed agents
-* **ProjectInitializer enhancements** - DONE
-  - Added Makefile creation to ProjectInitializer for complete greenfield setup
-  - Implemented comprehensive project scaffolding
-* **Test framework stability** - DONE
-  - Fixed all failing tests for agent framework updates
-  - Achieved 100% test pass rate across all components
-* **Documentation and tutorial creation** - DONE
-  - Updated documentation with correct agent names
-  - Created HelloWorld tutorial for new users
-  - Comprehensive onboarding experience established
-
-### ✅ Completed: Production Readiness
-* **Scenario 1 state achievement** - DONE
-  - Scenario 1 (establish codebase from scratch) is now excellent and production-ready
-  - Complete end-to-end workflow for greenfield projects
-  - Robust agent selection and project initialization
-
-***
-
-## [COMPLETED] - *Production Release with Release Management - Version 1.0.0*
-
-### ✅ Completed: Release Management System
-* **Complete release management system** with agent-releaseManager - DONE
-  - 6 structured make targets for complete release workflow
-  - `release-check` - Validate release readiness with comprehensive checklist
-  - `release-prepare` - Build packages and prepare for publication
-  - `release-test` - Test publication workflow using TestPyPI
-  - `release-publish` - Publish to production PyPI with safety checks
-  - `release-finalize` - Post-release tasks (tags, GitHub releases, documentation)
-  - `release-rollback` - Emergency rollback procedures and guidance
-* **Local package installation capability** - DONE
-  - `make install-local` target for PyPI-equivalent testing
-  - Local package building and installation workflow
-  - Integration testing with locally built packages
-* **Documentation updates for installation options** - DONE
-  - Updated documentation to reflect all installation methods
-  - PyPI installation guidance and local development setup
-  - Complete user onboarding documentation
-* **Package distribution readiness** - DONE
-  - Full package ready for PyPI publication
-  - All agents included in package data distribution
-  - Console script entry point for global CLI availability
-  - Version 1.0.0 production release achieved
-
-***
-
-## [COMPLETED] - *Scenario 2: Existing Project Integration Excellence - Version 0.2.2*
-
-### ✅ Completed: Scenario 2 Tasks
-* **Scenario 2 exploration: Integration with existing projects having agents** - DONE
-  - Research detection of existing agent systems in projects - DONE
-  - Design conflict resolution strategies for overlapping agent functionality - DONE
-  - Create migration paths for replacing outdated project-specific agents - DONE
-  - Develop extension mechanisms for project-specific kaizen agent customizations - DONE
-  - Define integration patterns that respect existing project structure - DONE
-  - Build tooling for safe agent system transitions - DONE
-
-### ✅ Completed: Major Components Built
-* **Detection system (detection.py)** for analyzing existing agent systems - DONE
-  - Comprehensive agent system detection across multiple formats
-  - Analysis of conflicts and overlap identification
-  - Integration readiness assessment
-* **Migration framework (migration.py)** with 5 migration strategies - DONE
-  - Replace strategy for complete agent replacement
-  - Merge strategy for combining functionalities
-  - Extend strategy for adding new capabilities
-  - Coexist strategy for parallel operation
-  - Archive strategy for deprecation handling
-* **Extension system (extensions.py)** for project-specific customizations - DONE
-  - Plugin-based architecture for agent customization
-  - Dynamic loading and configuration management
-  - Safe extension isolation and validation
-* **Complete CLI integration** with detect, migrate, and extensions commands - DONE
-  - kaizen-agentic detect command for system analysis
-  - kaizen-agentic migrate command with strategy selection
-  - kaizen-agentic extensions command for customization management
-* **Integration patterns documentation** with 5 proven scenarios - DONE
-  - Established patterns for common integration scenarios
-  - Best practices for safe agent system transitions
-  - Comprehensive documentation and examples
-
-### ✅ Completed: Production Readiness
-* **Scenario 2 state achievement** - DONE
-  - Scenario 2 (existing project integration) is now excellent and production-ready
-  - Complete detection, migration, and extension capabilities
-  - Safe and reliable agent system transitions
-  - Both Scenario 1 (greenfield) and Scenario 2 (existing projects) are production-ready

agents/agent-coach.md

@@ -0,0 +1,184 @@
+---
+name: coach
+description: Coaching meta-agent that reads all agent memories in a project and synthesises cross-agent briefs and new-agent orientations
+category: meta
+memory: enabled
+---
+
+# Coach Agent
+
+## Role
+
+You are the **kaizen-agentic Coach** — a meta-agent that observes, synthesises,
+and advises. You do not perform domain work (coding, testing, infrastructure).
+Your sole purpose is to read across the accumulated memories of all agents in a
+project and produce useful, targeted briefs.
+
+You are invoked via:
+```
+kaizen-agentic memory brief <agent-name>
+```
+
+Or directly by the operator: *"Coach, brief the sys-medic agent on this project"*
+or *"Coach, what patterns have you observed across all agents?"*
+
+---
+
+## What You Do
+
+### 1. Cross-Agent Synthesis
+
+Read all `.kaizen/agents/*/memory.md` files in the current project. Identify:
+
+- **Shared patterns**: themes that appear across multiple agents
+  (e.g. "three agents flagged missing test coverage as a risk")
+- **Cross-domain risks**: signals in one agent's memory that should inform
+  another (e.g. infrastructure instability flagged by sys-medic → tdd-workflow
+  should account for flaky environments)
+- **Resource or architectural signals**: recurring mentions of specific files,
+  modules, services, or systems across agents
+- **Contradictions or gaps**: where agents hold conflicting assumptions or where
+  no agent has coverage
+
+### 2. New-Agent Orientation
+
+When asked to brief a specific agent about to be deployed for the first time:
+
+1. Read all existing agent memories in the project
+2. Filter for what is relevant to the incoming agent's domain
+3. Produce a targeted orientation brief covering:
+   - **Project context**: what kind of project this is, key constraints
+   - **What to know first**: the most important facts for this agent
+   - **Watch points**: risks or pitfalls flagged by other agents that are relevant
+   - **What has worked**: successful approaches in adjacent domains
+   - **Open threads**: unresolved items from other agents that may interact with
+     this agent's work
+
+### 3. Fleet Health Overview
+
+When asked for a fleet overview:
+
+- Summarise the health of the agent fleet: which agents are active, stale, or
+  missing from the project
+- Flag agents with high `session_count` and still-open `## Open Threads`
+- Identify agents whose memories suggest overlapping concerns
+- Recommend whether any memory files should be reviewed or reset
+
+---
+
+## How to Read Agent Memory Files
+
+Memory files live at `.kaizen/agents/<name>/memory.md` relative to the project
+root. Each follows ADR-002 structure:
+
+```
+## Project Context      ← agent's understanding of the project
+## Accumulated Findings ← patterns and recurring issues
+## What Worked         ← validated approaches
+## Watch Points        ← risks and traps
+## Open Threads        ← unresolved items
+## Session Log         ← chronological session summaries
+```
+
+When synthesising, weight `## Watch Points` and `## Open Threads` most heavily —
+these are the signals most likely to be actionable for another agent.
+
+### Project metrics (ADR-004)
+
+Quantitative performance data lives at `.kaizen/metrics/<agent>/summary.json`.
+`kaizen-agentic memory brief <agent>` includes a `## Performance Summary` block
+when metrics exist.
+
+When synthesising orientations:
+
+- Combine qualitative memory with quantitative trends (success rate, quality,
+  execution time, trend arrows)
+- Flag agents with declining success rate or quality trends
+- Cross-reference metrics with `## Watch Points` — do metrics confirm or
+  contradict qualitative findings?
+- Note when an agent has memory but no metrics (incomplete session-close protocol)
+
+Fleet optimizer output at `.kaizen/metrics/optimizer/analysis.json` provides
+project-wide analysis from `kaizen-agentic metrics optimize`.
+
+---
+
+## Output Format
+
+### Cross-agent brief
+
+```
+## Cross-Agent Brief — <project name>
+Generated: <date>
+Agents with memory: <list>
+
+### Shared Patterns
+<bullet list of themes appearing across ≥2 agents>
+
+### Cross-Domain Risks
+<risks from one domain relevant to others>
+
+### Open Threads (fleet-wide)
+<unresolved items that span or affect multiple agents>
+
+### Fleet Health
+<which agents are active/stale, any concerning signals>
+```
+
+### New-agent orientation
+
+```
+## Orientation Brief for: <agent-name>
+Project: <project name>
+Generated: <date>
+Sources: <which agent memories were read>
+
+### Performance Summary
+<from .kaizen/metrics/<agent>/ when available — success rate, quality, trends>
+
+### What to Know First
+<3–5 most important facts for this agent>
+
+### Watch Points
+<risks relevant to this agent's domain>
+
+### What Has Worked
+<approaches validated by other agents that apply here>
+
+### Open Threads You May Encounter
+<items from other agents that may intersect with your work>
+```
+
+---
+
+## Behaviour Boundaries
+
+- **Do not** modify agent memory files
+- **Do not** perform any domain-specific work (coding, testing, diagnosis)
+- **Do not** make decisions — synthesise and advise only
+- **If no memories exist**: say so clearly and offer to help initialise them
+- **If asked about a specific agent not present**: note the gap
+
+---
+
+## Coach's Own Memory
+
+The coach maintains `.kaizen/agents/coach/memory.md` covering:
+
+- Fleet-level patterns observed over time
+- How the agent population in this project has evolved
+- Meta-observations about how well the memory convention is being followed
+- Recurring gaps or blind spots in the agent fleet
+
+### Session Start
+
+1. Check for `.kaizen/agents/coach/memory.md`.
+2. If present, read it — prior fleet observations provide context for the current synthesis.
+3. Scan `.kaizen/agents/*/memory.md` to build the current fleet picture.
+
+### Session Close
+
+1. Update `## Accumulated Findings` with new fleet-level patterns.
+2. Note any new agents added or memory files reset.
+3. Append one line to `## Session Log`: `YYYY-MM-DD · <brief requested for> · <key finding>`.
+4. Bump `last_updated` and `session_count`.

agents/agent-code-refactoring.md

@@ -169,4 +169,4 @@ The agent focuses on practical, implementable improvements that align with proje
 - Identify and fix security vulnerabilities opportunistically
 - Recommend secure coding practices and patterns
 - Assess input validation and data sanitization
-- Evaluate dependency security and update recommendations
+- Evaluate dependency security and update recommendations

agents/agent-datamodel-optimization.md

@@ -179,4 +179,4 @@ Based on successful optimizations (e.g., IssueActivity), typical results include
 
 ---
 
-*This agent provides systematic datamodel optimization capabilities, ensuring consistent interfaces, reduced code duplication, and improved maintainability across all data structures in the codebase.*
+*This agent provides systematic datamodel optimization capabilities, ensuring consistent interfaces, reduced code duplication, and improved maintainability across all data structures in the codebase.*

agents/agent-keepaChangelog.md

@@ -284,4 +284,4 @@ When updating or creating changelog files:
 - Indicate urgency of security updates
 - Consider separate security advisory for critical issues
 
-Remember: Your role is to make version history clear, accessible, and useful for users, maintainers, and stakeholders. Always consider the audience and their need to understand what changed and why it matters.
+Remember: Your role is to make version history clear, accessible, and useful for users, maintainers, and stakeholders. Always consider the audience and their need to understand what changed and why it matters.

agents/agent-keepaContributingfile.md

@@ -362,4 +362,4 @@ When updating or creating contributing files:
 - Governance and decision-making processes
 - Release and maintenance responsibilities
 
-Remember: Your role is to make contributing accessible, clear, and aligned with project goals. Always consider the contributor experience and remove barriers to meaningful participation while maintaining project quality and consistency.
+Remember: Your role is to make contributing accessible, clear, and aligned with project goals. Always consider the contributor experience and remove barriers to meaningful participation while maintaining project quality and consistency.

agents/agent-keepaTodofile.md

@@ -236,4 +236,4 @@ When updating or creating todo files:
 - Poor priority assessment
 - Missing dependencies or blockers
 
-Remember: Your role is to make todo management effortless and effective, enabling better focus and productivity. Always consider the human workflow and cognitive load when organizing and presenting tasks.
+Remember: Your role is to make todo management effortless and effective, enabling better focus and productivity. Always consider the human workflow and cognitive load when organizing and presenting tasks.

agents/agent-optimization.md

@@ -2,7 +2,8 @@
 name: optimization
 description: Meta-agent that analyzes and optimizes other Claude Code subagents based on their performance data, usage patterns, and effectiveness metrics. Use PROACTIVELY for agent ecosystem improvement.
 model: inherit
-category: infrastructure
+category: meta
+memory: enabled
 ---
 
 # Kaizen Optimizer - Agent Performance Meta-Optimizer
@@ -166,4 +167,25 @@ This agent operates within Claude Code's conversation context and focuses on:
 - **Ecosystem Balance**: Ensuring agents complement rather than compete with each other
 - **Practical Improvements**: Recommendations that can be implemented through specification updates
 
-The agent serves as the continuous improvement engine for the subagent ecosystem, ensuring agents evolve to better serve user needs and project requirements.
+The agent serves as the continuous improvement engine for the subagent ecosystem, ensuring agents evolve to better serve user needs and project requirements.
+
+## Session Start
+
+1. Check for `.kaizen/agents/optimization/memory.md` in the project root.
+2. If present, read it before beginning analysis.
+3. Review `.kaizen/metrics/optimizer/analysis.json` if it exists for the latest fleet report.
+
+## Session Close
+
+1. When analysis completes, note key findings in `## Accumulated Findings`.
+2. Append one line to `## Session Log`: `YYYY-MM-DD · <agents reviewed> · <outcome>`.
+3. Bump `last_updated` and increment `session_count`.
+4. Persist quantitative analysis via CLI (ADR-004):
+
+```bash
+kaizen-agentic metrics optimize [agent-name]
+```
+
+Run without an agent name to analyze all agents with project metrics. Requires
+≥10 execution records per agent for actionable recommendations (see
+`wiki/AgentKaizenOptimizer.md`).

agents/agent-priority-evaluation.md

@@ -6,10 +6,9 @@ category: project-management
 
 ## Instructions
 
-You are the priority assistant helping with project planning and deciding what to do first. 
+You are the priority assistant helping with project planning and deciding what to do first.
 Your goal is to keep in mind the current focus area of tasks and it's relation to the big picture of where we want to go.
 You are responsible for evaluating alternatives to effectively achieving project goals, milestones and the overall mission.
 You look out for important decisions or variants of how to move forward and use weighted shortest job first to score tasks and issues to provide perspective and guidance.
 
 When asked about a task or issue you establish a wsjf-score and report on the overall score and each dimension to establish it. You supplement this information with additional risk information especially if the decision and resulting implementation might be impossible, hard or expensive to role back.
-

agents/agent-project-assistant.md

@@ -28,8 +28,8 @@ You are the MarkiTect project assistant, specialized in providing project status
 **Repository Structure:**
 - Main project hosted on Gitea with issue tracking for use cases and tasks
 - Planning documentation goes to roadmap/ROADMAPTOPIC subdirectories
-- Closed roadmap-topic-directories git-mv to history/ 
-- Auto generated documentation maintained in docs/ 
+- Closed roadmap-topic-directories git-mv to history/
+- Auto generated documentation maintained in docs/
 - Human generated documentation maintained in wiki/ submodule
 - Test-driven development workflow with comprehensive test coverage
 
@@ -63,7 +63,7 @@ Important: Respect the directory structure! If in doubt ask or use directories u
 
 When asked about project status or next steps:
 
-1. **Start with Current State**: Always check TODO.md for the latest activity 
+1. **Start with Current State**: Always check TODO.md for the latest activity
 2. **Review Recent Progress**: Check CHANGELOG.md for previous work and progress
 3. **Check Planned Work**: TODO.md documents next steps and priorities, if empty see topics in roadmap/
 4. **Project Scope and Goals**: Vision, Mission, Guidelines and Usecases live in wiki/ if available
@@ -87,7 +87,7 @@ When asked about project status or next steps:
 - Do NOT implement immediately - issues are for tracking and planning
 
 **Issue vs. Immediate Work:**
-- Current session planned work: document in TODO.md and roadmap/ROADMAPTOPIC 
+- Current session planned work: document in TODO.md and roadmap/ROADMAPTOPIC
 - Discovered improvements: add to workplan in roadmap topic, continue with planned work
 - Critical bugs affecting current work: fix immediately, then create issue for root cause analysis
 - Future enhancements: note in roadmap-topic to create issues first for proper planning
@@ -123,10 +123,10 @@ When asked what's up for a new coding session, follow this standardized routine:
 1. **Mission Status**: Provide reminder to project vision and how we are doing
 2. **Recently**: Provide reminder what we did last from the last entry to the diary
 3. **TODO.md**: Check if we provided guidance for what to do next at the end of the last coding session
-4. **git status**: Check if git is clean or work has been left unfinished 
+4. **git status**: Check if git is clean or work has been left unfinished
 5. **Workspace clean**: Check if workspace is clean or we left of in the middle of a TDD cycle
 6. **Topic or issue finished**: Check if we are currently working on a specific roadmap-topic or issue
-7. **Suggestion**: Provide a sensible suggestion of what to do next 
+7. **Suggestion**: Provide a sensible suggestion of what to do next
 
 ## Session Wrap-Up Protocol
 
@@ -170,7 +170,7 @@ Ready for commit: [list of files to commit]
 **Hunch**: Ideas to explore that need consideration if useful and in scope
 **Hickups**: Notes on inefficient or roundtripping implementation to analyse later
 
-Collect these in the roadmap-topic-directory and move stuff to eat-the-frog on close if unfinished 
+Collect these in the roadmap-topic-directory and move stuff to eat-the-frog on close if unfinished
 
 ### Example Issue Creation During Development:
 **Scenario**: While implementing CLI commands, discover that error messages could be improved
@@ -178,6 +178,20 @@ Collect these in the roadmap-topic-directory and move stuff to eat-the-frog on c
 **Result**: Continue with current CLI implementation, address error enhancement in future session
 
 Generate issues for relevantly expensive or risky stuff and in direct feedback with developers.
-Controled in-scope-work does not need the costly issue capture, refinement, selection roundtrip. 
+Controled in-scope-work does not need the costly issue capture, refinement, selection roundtrip.
 
 Remember: Your role is to help developers quickly understand "where we are" and "what should we do next" when picking up work on the MarkiTect project, and to ensure proper session wrap-up for continuity.
+
+---
+
+## Session Start
+
+1. Check for `.kaizen/agents/project-management/memory.md` in the project root.
+2. If present, read it and surface relevant context (last session summary, open threads, watch points) in your opening brief.
+3. If absent, offer to initialise with `kaizen-agentic memory init project-management`.
+
+## Session Close
+
+1. Update `## Accumulated Findings`, `## What Worked`, `## Watch Points` based on this session.
+2. Append one line to `## Session Log`: `YYYY-MM-DD · <brief summary> · <outcome>`.
+3. Bump `last_updated` to today and increment `session_count`.

agents/agent-releaseManager.md

@@ -98,4 +98,4 @@ When managing releases, always prioritize:
 1. **Security**: Never compromise on security practices
 2. **Reliability**: Thorough testing before publication
 3. **Communication**: Clear documentation and announcements
-4. **Reproducibility**: Consistent and documented processes
+4. **Reproducibility**: Consistent and documented processes

agents/agent-requirements-engineering.md

@@ -484,4 +484,19 @@ The agent directly addresses the root causes:
 
 ---
 
-*This agent provides systematic foundation analysis and interface contract verification based on lessons learned from Issue #59 to prevent compatibility issues and ensure solid architectural foundations before implementation.*
+## Session Start
+
+1. Check for `.kaizen/agents/requirements-engineering/memory.md` in the project root.
+2. If present, read it — pay attention to `## Watch Points` (recurring interface pitfalls) and `## Accumulated Findings` (known domain model patterns).
+3. If absent, offer to initialise with `kaizen-agentic memory init requirements-engineering`.
+
+## Session Close
+
+1. Update `## Accumulated Findings` with any new interface contracts, domain model patterns, or mock alignment lessons from this session.
+2. Update `## Watch Points` with any newly discovered incompatibility risks.
+3. Append one line to `## Session Log`: `YYYY-MM-DD · <feature or component analysed> · <outcome>`.
+4. Bump `last_updated` to today and increment `session_count`.
+
+---
+
+*This agent provides systematic foundation analysis and interface contract verification based on lessons learned from Issue #59 to prevent compatibility issues and ensure solid architectural foundations before implementation.*

agents/agent-scope-analyst.md

@@ -309,6 +309,23 @@ Use this structure when creating or rewriting SCOPE.md:
 
 ---
 
+## Provided Capabilities
+
+<!-- What can this repo's domain provide to other domains on request? -->
+<!-- Each capability block is parsed by the state-hub capability catalog ingest. -->
+<!-- Remove the examples and add your own, or leave empty if none. -->
+
+<!--
+```capability
+type: infrastructure
+title: Example capability title
+description: What this capability provides, in one or two sentences.
+keywords: [keyword1, keyword2, keyword3]
+```
+-->
+
+---
+
 ## Notes
 
 <!-- Anything else worth knowing. Keep it short. -->
@@ -353,3 +370,17 @@ A good result allows a reader to quickly answer:
 - Is it overlapping something else?
 
 If those are clear, the task is successful.
+
+---
+
+## Session Start
+
+1. Check for `.kaizen/agents/scope-analyst/memory.md` in the project root.
+2. If present, read it — prior SCOPE.md analyses and boundary decisions may be useful context.
+3. If absent, this is typically fine for a first-run analysis.
+
+## Session Close
+
+1. If a SCOPE.md was produced or meaningfully revised, note the key boundary decisions in `## Accumulated Findings`.
+2. Append one line to `## Session Log`: `YYYY-MM-DD · <repo analysed> · <outcome>`.
+3. Bump `last_updated` to today and increment `session_count`.

agents/agent-setupRepository.md

@@ -412,4 +412,4 @@ When setting up or checking repositories, always verify that:
 - Standards compliance is treated as a required test, not optional check
 - Missing .gitignore or other essential files will be caught automatically
 
-Remember: Your role is to transform repository stubs into production-ready Python projects that follow industry best practices, enable efficient development workflows, and provide a solid foundation for long-term project success.
+Remember: Your role is to transform repository stubs into production-ready Python projects that follow industry best practices, enable efficient development workflows, and provide a solid foundation for long-term project success.

agents/agent-sys-medic.md

@@ -2,9 +2,31 @@
 name: sys-medic
 description: Linux/Kubernetes node health assessment agent — diagnoses process, memory, CPU, disk, network, and kubelet issues with safe, prioritized, evidence-driven guidance
 category: infrastructure
+memory: enabled
 source: sys-medic (~/sys-medic/agent-sys-medic.md)
 ---
 
+# Session Start Protocol
+
+1. Check for `.kaizen/agents/sys-medic/memory.md` in the project root.
+2. If present, read it — pay particular attention to `## Node Profiles` (known baselines
+   per host) and `## Recurring Findings` (issues seen before on this infrastructure).
+3. Acknowledge memory in your opening brief: note any relevant node profiles or prior findings.
+4. If a structured assessment is requested, check for
+   `agents/protocols/sys-medic/k3s-node-health-assessment.md` and use it as your procedure.
+
+# Session Close Protocol
+
+1. Update `## Node Profiles` — add or revise the entry for any host assessed this session
+   (hostname | typical load | known quirks | last assessment date).
+2. Update `## Recurring Findings` — if an issue was seen previously, increment its frequency
+   and note the date.
+3. Update `## Accumulated Findings`, `## What Worked`, `## Watch Points` as appropriate.
+4. Append one line to `## Session Log`: `YYYY-MM-DD · <host(s) assessed> · <key finding> · <outcome>`.
+5. Bump `last_updated` and `session_count`.
+
+---
+
 You are SysMedic, a careful coding and systems operations agent for Linux-based Kubernetes environments.
 
 Your role is to assess operational health, identify signs of instability, and provide safe, practical guidance to improve system condition. You are not a blind automation bot. You are an evidence-driven operational analyst and remediation advisor.
@@ -306,4 +328,39 @@ When invoked, begin by determining the current operational picture and producing
 - signs of instability
 - safe guidance for stabilization
 
+If a structured assessment is requested, use the k3s-node-health-assessment protocol
+(`agents/protocols/sys-medic/k3s-node-health-assessment.md`) if available. The protocol
+provides a step-by-step procedure covering OS baseline, process hygiene, memory, CPU,
+disk, network, Kubernetes node state, and k3s runtime health.
+
 If insufficient evidence is available, state exactly which safe inspection commands should be run next.
+
+---
+
+# Memory Template Extensions
+
+sys-medic's memory file (`.kaizen/agents/sys-medic/memory.md`) extends the base template
+(ADR-002) with three additional sections:
+
+```markdown
+## Node Profiles
+<!-- Per-node operational baseline established over sessions -->
+<!-- hostname | typical load | known quirks | last assessment date -->
+
+## Recurring Findings
+<!-- Issues seen more than once: pattern · first seen · frequency -->
+
+## Cleared Issues
+<!-- Issues that were resolved: what was done · when · outcome -->
+```
+
+These sections are maintained by the session-close protocol above.
+
+---
+
+# Related Documents
+
+- **Protocol runbook:** `agents/protocols/sys-medic/k3s-node-health-assessment.md`
+- **Memory convention:** `docs/adr/ADR-002-project-memory-convention.md`
+- **Protocols convention:** `docs/adr/ADR-003-protocols-artifact-convention.md`
+- **Agency framework:** `docs/agency-framework.md`

agents/agent-tdd-workflow.md

@@ -2,6 +2,21 @@
 name: tdd-workflow
 description: Expert guidance for the TDD8 workflow methodology, specializing in the comprehensive ISSUE-TEST-RED-GREEN-REFACTOR-DOCUMENT-REFINE-PUBLISH cycle with sophisticated sidequest management and proper test organization.
 category: development-process
+memory: enabled
+metrics:
+  primary:
+    name: test_pass_rate
+    description: Share of acceptance-criteria tests passing at PUBLISH
+    measurement: passing_tests / total_tests for the active issue workspace
+    target: 1.0
+  secondary:
+    - name: cycle_time_s
+      description: Wall-clock time from ISSUE start to PUBLISH
+      measurement: Session duration in seconds (execution_time_s in ADR-004)
+  collection:
+    frequency: per_execution
+    storage: .kaizen/metrics/tdd-workflow/
+    retention: 180d
 ---
 
 # TDDAi Assistant Agent
@@ -128,7 +143,7 @@ You understand the workspace structure (default: `.tddai_workspace/`, configurab
 - `DIRTY` - Workspace directory exists but no current issue file
 
 ### Test Development Best Practices
-**Test Naming Convention:** 
+**Test Naming Convention:**
 - `test_{capability}_issue_{NUM}_{scenario}.py`
 
 **Required Test Structure:**
@@ -357,3 +372,35 @@ Remember: The goal is to build software incrementally using the proven TDD8 cycl
 **ISSUE-TEST-RED-GREEN-REFACTOR-DOCUMENT-REFINE-PUBLISH**
 
 The comprehensive 8-step development methodology that transforms requirements into production-ready, well-tested, documented functionality while maintaining code quality and project momentum through intelligent sidequest management.
+
+---
+
+## Session Start
+
+1. Check for `.kaizen/agents/tdd-workflow/memory.md` in the project root.
+2. If present, read it — pay attention to `## Watch Points` (recurring test pitfalls) and `## What Worked` (effective patterns for this project).
+3. If absent, offer to initialise with `kaizen-agentic memory init tdd-workflow`.
+
+## Session Close
+
+1. Update `## Accumulated Findings` with any new TDD patterns or recurring failure modes observed.
+2. Update `## What Worked` and `## Watch Points` as needed.
+3. Append one line to `## Session Log`: `YYYY-MM-DD · <issue or feature> · <outcome>`.
+4. Bump `last_updated` to today and increment `session_count`.
+5. Record session metrics (ADR-004; adjust values to match outcome):
+
+```bash
+# Successful PUBLISH — all acceptance tests green:
+echo '{"success": true, "execution_time_s": <seconds>, "quality_score": 0.9, "primary_metric": {"name": "test_pass_rate", "value": 1.0, "target": 1.0}, "metadata": {"issue": "<NUM>", "phase": "PUBLISH"}}' \
+  | kaizen-agentic metrics record tdd-workflow --json --idempotency-key <session-id>
+
+# Incomplete or failed cycle:
+echo '{"success": false, "execution_time_s": <seconds>, "quality_score": 0.4, "primary_metric": {"name": "test_pass_rate", "value": <rate>, "target": 1.0}, "metadata": {"issue": "<NUM>", "phase": "<last-phase>"}}' \
+  | kaizen-agentic metrics record tdd-workflow --json --idempotency-key <session-id>
+```
+
+Shorthand when only outcome and duration matter:
+
+```bash
+kaizen-agentic metrics record tdd-workflow --success --time <seconds> --quality <0.0-1.0>
+```

agents/agent-test-maintenance.md

@@ -141,4 +141,4 @@ ACTION: Change import path, verify test logic still valid
 - **Communicate trade-offs** when removing functionality
 - **Maintain backward compatibility** where feasible
 
-This agent ensures the MarkiTect project maintains a robust, reliable test suite that accurately reflects the current codebase architecture and functionality.
+This agent ensures the MarkiTect project maintains a robust, reliable test suite that accurately reflects the current codebase architecture and functionality.

agents/agent-testing-efficiency.md

@@ -291,4 +291,4 @@ markers =
 
 ---
 
-*This agent provides specialized test execution optimization focused on TDD8 workflow enhancement, pytest reliability resolution, and systematic testing efficiency improvements for development velocity.*
+*This agent provides specialized test execution optimization focused on TDD8 workflow enhancement, pytest reliability resolution, and systematic testing efficiency improvements for development velocity.*

agents/agent-tooling-optimization.md

@@ -196,4 +196,4 @@ RECOMMENDATION: Suggest primary tools and deprecation plan for others
 IMPLEMENTATION: Provide migration guide and updated documentation
 ```
 
-This agent ensures the MarkiTect project maintains an optimized, efficient tooling ecosystem that maximizes developer productivity and minimizes friction in development workflows.
+This agent ensures the MarkiTect project maintains an optimized, efficient tooling ecosystem that maximizes developer productivity and minimizes friction in development workflows.

agents/protocols/README.md

@@ -0,0 +1,40 @@
+# Agent Protocols
+
+This directory contains **protocol runbooks** — structured, human-readable procedural documents that kaizen-agentic agents reference during structured assessments or remediation work.
+
+Protocols are distinct from agent prompts:
+- **Agent prompts** (`agents/agent-*.md`) shape AI behaviour
+- **Protocols** (`agents/protocols/<agent>/<slug>.md`) are procedural checklists for humans and agents to execute
+
+See [ADR-003](../../docs/adr/ADR-003-protocols-artifact-convention.md) for the full convention.
+
+## Structure
+
+```
+agents/protocols/
+  <agent-name>/
+    <slug>.md    ← one file per protocol
+```
+
+## Available Protocols
+
+| Agent | Protocol | Description |
+|-------|----------|-------------|
+| sys-medic | [k3s-node-health-assessment](sys-medic/k3s-node-health-assessment.md) | Structured k3s node health check covering kubelet, pods, resources, networking, and storage |
+
+## Usage
+
+**From the CLI:**
+
+```bash
+kaizen-agentic protocols list                     # List all protocols
+kaizen-agentic protocols list sys-medic           # List sys-medic protocols
+kaizen-agentic protocols show sys-medic k3s-node-health-assessment
+```
+
+**From an agent session:**
+
+When an agent references a protocol, it will say something like:
+> *"Use the k3s-node-health-assessment protocol at `agents/protocols/sys-medic/k3s-node-health-assessment.md` for this assessment."*
+
+Protocols can also be read and executed directly without an AI agent.

agents/protocols/sys-medic/k3s-node-health-assessment.md

@@ -0,0 +1,306 @@
+---
+agent: sys-medic
+slug: k3s-node-health-assessment
+title: k3s Node Health Assessment
+version: 1.0.0
+last_updated: "2026-03-18"
+---
+
+# k3s Node Health Assessment
+
+## Purpose
+
+Structured health assessment for a Linux host running k3s (lightweight Kubernetes). Covers OS baseline, process hygiene, memory, CPU, disk, network, Kubernetes node state, and runtime services. Produces a prioritized findings report with safe next actions.
+
+## Scope
+
+- Linux host (any distribution) running k3s
+- k3s worker nodes and single-node clusters
+- Hosts where `kubectl` and/or `k3s kubectl` are available
+- Applies whether the host is healthy, degraded, or in an unknown state
+
+## Prerequisites
+
+- Shell access to the target host (SSH or console)
+- Ideally: sudo or root access (some checks require it)
+- Available tools: `ps`, `top`, `free`, `vmstat`, `iostat`, `ss`, `journalctl`, `systemctl`, `dmesg`, `df`, `du`, `lsof`, `kubectl` or `k3s kubectl`
+- Note which tools are absent — record what could not be checked
+
+---
+
+## Procedure
+
+### Step 1 — OS and Node Baseline
+
+Establish context before diagnosing anything.
+
+```bash
+hostname
+uptime
+uname -r
+nproc
+free -h
+swapon --show
+df -h
+date
+```
+
+Record:
+- Hostname and uptime
+- Kernel version
+- CPU core count
+- Total/used/free memory and swap
+- Overall disk usage per mount
+- Current time (for correlating log timestamps)
+
+---
+
+### Step 2 — Process Hygiene
+
+```bash
+# Zombie and D-state processes
+ps aux | awk '$8 ~ /^[ZD]/ {print}'
+
+# Top memory consumers
+ps aux --sort=-%mem | head -20
+
+# Top CPU consumers
+ps aux --sort=-%cpu | head -20
+
+# Processes with high FD counts (requires lsof)
+sudo lsof 2>/dev/null | awk '{print $2}' | sort | uniq -c | sort -rn | head -20
+
+# Long-running suspicious processes (> 7 days)
+ps -eo pid,user,etime,comm --sort=-etime | head -30
+```
+
+Look for:
+- Zombie count > 0
+- D-state (uninterruptible sleep) tasks
+- Unexpected high-memory or high-CPU processes
+- Stale maintenance scripts, port-forwards, debug sessions, rsync, or backup jobs
+- Orphaned shells or user sessions
+
+---
+
+### Step 3 — Memory Health
+
+```bash
+# Overall memory picture
+free -h
+cat /proc/meminfo | grep -E 'MemAvailable|SwapFree|Dirty|Slab|KReclaimable'
+
+# OOM kill history
+sudo dmesg | grep -i 'oom\|killed process' | tail -20
+sudo journalctl -k --since "24 hours ago" | grep -i 'oom\|out of memory' | tail -20
+
+# Slab usage
+sudo slabtop -o | head -30
+
+# cgroup memory pressure (if cgroups v2)
+find /sys/fs/cgroup -name "memory.pressure" 2>/dev/null | xargs grep -l "some" 2>/dev/null | head -10
+```
+
+Look for:
+- Available memory < 10% of total
+- Swap being actively used (churn is worse than swap in use)
+- Recent OOM kills
+- High slab growth
+- cgroup memory pressure events
+
+---
+
+### Step 4 — CPU and Scheduler Health
+
+```bash
+# Load average vs core count
+uptime
+nproc
+
+# CPU idle and steal
+top -bn1 | grep '%Cpu'
+vmstat 1 5
+
+# Run queue pressure
+vmstat 1 5 | awk '{print $1, $2}'   # r=running, b=blocked
+```
+
+Look for:
+- Load average persistently > core count
+- CPU idle < 10%
+- High CPU steal (virtualised hosts)
+- Run queue (r) > core count sustained
+- Blocked processes (b) > 0 sustained
+
+---
+
+### Step 5 — Disk and Filesystem Health
+
+```bash
+# Disk usage
+df -h
+df -i  # inode usage
+
+# Large log files
+sudo du -sh /var/log/* 2>/dev/null | sort -rh | head -20
+sudo journalctl --disk-usage
+
+# k3s data directory
+sudo du -sh /var/lib/rancher/k3s/ 2>/dev/null
+sudo du -sh /var/lib/rancher/k3s/agent/containerd/ 2>/dev/null
+
+# Rapidly growing dirs (compare two snapshots 60s apart)
+sudo du -sh /var/lib/rancher /var/log /tmp 2>/dev/null
+```
+
+Look for:
+- Any mount > 85% full (warning) or > 95% (critical)
+- Any mount with inode usage > 85%
+- Container image accumulation in containerd storage
+- Large or rapidly growing log files
+- Abandoned temp files
+
+---
+
+### Step 6 — Network and Connection State
+
+```bash
+# Connection state summary
+ss -s
+ss -tnp | awk '{print $1}' | sort | uniq -c | sort -rn
+
+# Unusual listeners
+ss -tlnp
+
+# CLOSE_WAIT accumulation (application socket leak)
+ss -tnp | grep CLOSE_WAIT | wc -l
+
+# TIME_WAIT count (normal but high counts may indicate connection thrash)
+ss -tnp | grep TIME_WAIT | wc -l
+```
+
+Look for:
+- CLOSE_WAIT count > 50 (application not closing sockets)
+- SYN_RECV accumulation (connection flood or backlog issue)
+- Unexpected listeners on unusual ports
+- Long-lived unexpected tunnels or port-forwards
+
+---
+
+### Step 7 — Kubernetes Node Health
+
+```bash
+# Node status and conditions
+kubectl get node $(hostname) -o wide 2>/dev/null || k3s kubectl get node $(hostname) -o wide
+
+# Node conditions in detail
+kubectl describe node $(hostname) 2>/dev/null | grep -A 10 'Conditions:'
+
+# Resource pressure
+kubectl top node $(hostname) 2>/dev/null
+
+# Recent node events
+kubectl get events --field-selector involvedObject.name=$(hostname) --sort-by='.lastTimestamp' 2>/dev/null | tail -20
+
+# Top pods by resource use
+kubectl top pods --all-namespaces --sort-by=memory 2>/dev/null | head -20
+
+# Restarting pods on this node
+kubectl get pods --all-namespaces --field-selector spec.nodeName=$(hostname) 2>/dev/null | awk '$5 > 5 {print}'
+```
+
+Look for:
+- Node Ready=False or Unknown
+- MemoryPressure, DiskPressure, PIDPressure, or NetworkUnavailable = True
+- Pods with high restart counts (> 5)
+- CrashLoopBackOff workloads
+- Evicted pods (indicates past resource pressure)
+
+---
+
+### Step 8 — k3s Runtime and Control Services
+
+```bash
+# k3s service status
+sudo systemctl status k3s 2>/dev/null || sudo systemctl status k3s-agent
+
+# k3s recent logs (last 100 lines)
+sudo journalctl -u k3s --since "1 hour ago" -n 100 2>/dev/null || \
+sudo journalctl -u k3s-agent --since "1 hour ago" -n 100
+
+# containerd status (k3s embedded)
+sudo systemctl status containerd 2>/dev/null
+
+# CNI / flannel if applicable
+sudo systemctl status flanneld 2>/dev/null
+sudo ip addr show flannel.1 2>/dev/null
+```
+
+Look for:
+- k3s service not running or in failed state
+- Repeated restart entries in k3s logs
+- PLEG errors, image GC failures, sandbox creation failures
+- cgroup-related errors
+- API server timeout messages (on worker nodes: etcd or API server unreachable)
+
+---
+
+## Interpretation
+
+| Signal | Normal | Warning | Critical |
+|--------|--------|---------|----------|
+| Load average | ≤ core count | 1–2× core count | > 2× sustained |
+| Memory available | > 20% | 10–20% | < 10% |
+| Disk usage | < 75% | 75–90% | > 90% |
+| Inode usage | < 75% | 75–90% | > 90% |
+| Zombie count | 0 | 1–5 | > 5 or climbing |
+| OOM kills (24h) | 0 | 1–2 | > 2 or recent |
+| Pod restarts | < 3 | 3–10 | > 10 or CrashLoop |
+| CLOSE_WAIT | < 10 | 10–50 | > 50 |
+| Node Ready | True | — | False / Unknown |
+
+Confidence in findings:
+- **High** — direct evidence (OOM kill log, node condition set, error in service log)
+- **Medium** — indirect evidence (high memory use without OOM, rising load with no clear cause)
+- **Low** — circumstantial (aging process without other indicators)
+
+---
+
+## Remediation
+
+### High memory pressure
+
+1. Identify top consumers: `ps aux --sort=-%mem | head -20`
+2. Check for OOM history: `dmesg | grep -i oom`
+3. If a workload is leaking: restart the specific pod (not the node)
+4. If slab is high: check for inode-heavy workloads or NFS mounts
+5. Do not drop caches unless explicitly justified — Linux reclaims page cache automatically
+
+### Disk pressure
+
+1. Find largest directories: `du -sh /var/lib/rancher/k3s/agent/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/* | sort -rh | head -20`
+2. Prune unused container images: `k3s crictl rmi --prune` (safe — only removes unused images)
+3. Clear old journal logs: `sudo journalctl --vacuum-size=500M`
+4. Identify log-bloating pods and fix their logging config
+
+### k3s service failing
+
+1. Check service status: `sudo systemctl status k3s`
+2. Check logs: `sudo journalctl -u k3s -n 200`
+3. Common causes: etcd data corruption (single-node), API server unreachable (worker), disk full, cert expiry
+4. Do not restart k3s without understanding the cause — a restart may mask the issue
+
+### High pod restart count
+
+1. Check logs: `kubectl logs <pod> --previous`
+2. Check events: `kubectl describe pod <pod>`
+3. Distinguish OOMKilled (memory limit) from CrashLoop (application error) from Liveness probe failure
+
+---
+
+## Notes
+
+- This protocol was adapted from the sys-medic agent's structured assessment areas and the sys-medic repo's companion protocol document.
+- For single-node k3s clusters, the control plane (server) and data plane (agent) run on the same host — check both `k3s` and `k3s-agent` services.
+- On hosts without `kubectl` in PATH, use `k3s kubectl` as a drop-in replacement.
+- Protocol version history is tracked via the `version` frontmatter field. Update on significant structural changes.

docs/AGENT_DISTRIBUTION.md

@@ -13,13 +13,18 @@ The Kaizen Agentic framework provides a comprehensive system for distributing an
 
 ## Installation
 
-Install the Kaizen Agentic package:
+Install the Kaizen Agentic package from the Coulomb Gitea PyPI registry:
 
 ```bash
-pip install kaizen-agentic
+export GITEA_PACKAGE_USER=<gitea-user>
+export GITEA_PACKAGE_TOKEN=<package-token>
+
+pip install kaizen-agentic \
+  --extra-index-url "https://${GITEA_PACKAGE_USER}:${GITEA_PACKAGE_TOKEN}@gitea.coulomb.social/api/packages/coulomb/pypi/simple/"
 ```
 
-This provides the `kaizen-agentic` CLI tool for managing agents.
+This provides the `kaizen-agentic` CLI tool for managing agents. See
+[PACKAGE_RELEASE.md](PACKAGE_RELEASE.md) for pipx, local builds, and publishing.
 
 ## CLI Commands
 
@@ -373,10 +378,7 @@ If you're currently managing agents manually:
    ls agents/agent-*.md
    ```
 
-2. **Install Package**:
-   ```bash
-   pip install kaizen-agentic
-   ```
+2. **Install Package** (same as Installation section above).
 
 3. **Validate Current Setup**:
    ```bash
@@ -412,4 +414,4 @@ When updating Kaizen Agentic versions:
    kaizen-agentic validate
    ```
 
-This distribution system makes it easy to share and maintain consistent development workflows across all your projects using specialized AI agents.
+This distribution system makes it easy to share and maintain consistent development workflows across all your projects using specialized AI agents.

docs/CLI_CHEAT_SHEET.md

@@ -3,8 +3,15 @@
 Quick reference for the `kaizen-agentic` command-line tool.
 
 ## Installation
+
+From Coulomb Gitea PyPI (see [PACKAGE_RELEASE.md](PACKAGE_RELEASE.md)):
+
 ```bash
-pip install kaizen-agentic
+export GITEA_PACKAGE_USER=<gitea-user>
+export GITEA_PACKAGE_TOKEN=<package-token>
+
+pip install kaizen-agentic \
+  --extra-index-url "https://${GITEA_PACKAGE_USER}:${GITEA_PACKAGE_TOKEN}@gitea.coulomb.social/api/packages/coulomb/pypi/simple/"
 ```
 
 ## Core Commands
@@ -45,9 +52,79 @@ kaizen-agentic remove old-agent-name
 
 # Project status
 kaizen-agentic status                    # Show current project status
-kaizen-agentic validate                  # Validate agent installation
+kaizen-agentic validate                  # Validate agents (incl. frontmatter schema)
 ```
 
+### Authoring & Docs (WP-0007)
+```bash
+# Scaffold a new schema-valid agent (agents/agent-<name>.md)
+kaizen-agentic create-agent my-agent -c testing -d "What it does"
+kaizen-agentic create-agent my-agent     # prompts for category + description
+kaizen-agentic create-agent my-agent --force   # overwrite existing
+
+# Refresh the CLAUDE.md "Installed Agents" section from agent metadata
+kaizen-agentic docs generate             # idempotent rewrite
+kaizen-agentic docs generate --check     # CI gate: non-zero if out of date
+
+# validate enforces required name/description/category, valid category,
+# and valid memory/model values
+kaizen-agentic validate
+```
+
+After adding or editing agents, run `make agents-sync-package` so the packaged
+`data/agents/` copies stay in parity (release-check gate).
+
+### Project Metrics (ADR-004)
+```bash
+# Record outcome at session close
+kaizen-agentic metrics record tdd-workflow --success --time 120 --quality 0.9
+kaizen-agentic metrics record tdd-workflow --failure --time 45
+
+# Full JSON record from stdin
+echo '{"success": true, "quality_score": 1.0}' | kaizen-agentic metrics record tdd-workflow --json
+
+# Inspect metrics
+kaizen-agentic metrics show tdd-workflow
+kaizen-agentic metrics list
+kaizen-agentic metrics export tdd-workflow
+kaizen-agentic metrics optimize tdd-workflow   # analyze one agent (≥10 records)
+kaizen-agentic metrics optimize                # analyze all agents with metrics
+
+# Helix Forge correlation (fleet layer — agentic-resources)
+export HELIX_SESSION_UID="claude:<native-id>"
+kaizen-agentic metrics record tdd-workflow --success --time 120 --quality 0.9
+kaizen-agentic metrics correlate claude:<native-id>   # needs HELIX_STORE_DB
+
+# Publish optimizer evidence to artifact-store (optional)
+export ARTIFACTSTORE_API_URL=http://127.0.0.1:8000
+export ARTIFACTSTORE_API_TOKEN=<token>
+kaizen-agentic metrics publish
+
+# Scaffold memory + metrics together
+kaizen-agentic memory init tdd-workflow
+kaizen-agentic memory init tdd-workflow --no-metrics   # memory only
+```
+
+Session-close template: `docs/templates/session-close-protocol.md`
+
+### Scheduled Agent Execution (ADR-005)
+```bash
+# Opt this repo into fleet scheduling
+kaizen-agentic schedule init                  # coach + optimization weekly
+kaizen-agentic schedule init --timezone UTC   # override timezone
+kaizen-agentic schedule init --engagement coulomb-loop \
+  --agents coach,optimization --bootstrap-cadence hourly
+kaizen-agentic schedule validate              # schema + agent-name checks
+kaizen-agentic schedule list                  # enabled entries (--all incl. disabled)
+
+# Prepare orientation for a scheduled run (offline; no State Hub needed)
+kaizen-agentic schedule prepare coach                 # markdown bundle
+kaizen-agentic schedule prepare optimization --format json
+```
+
+activity-core fires the schedule and creates a task per (repo, agent); the task
+runs `schedule prepare`. kaizen-agentic does not run cron or invoke Claude.
+
 ### Information
 ```bash
 # List templates
@@ -92,7 +169,7 @@ kaizen-agentic status
 ```bash
 git clone team-repo
 cd team-repo
-pip install kaizen-agentic
+# Install CLI — see Installation section above
 kaizen-agentic status        # See what agents are used
 cat CLAUDE.md               # Read agent documentation
 ```
@@ -152,8 +229,7 @@ make agents-status    # Show detailed status
 
 ### Common Issues
 ```bash
-# Command not found
-pip install kaizen-agentic
+# Command not found — reinstall (see Installation section)
 
 # No agents directory
 kaizen-agentic install todo-keeper
@@ -194,4 +270,4 @@ kaizen-agentic update && kaizen-agentic validate
 ```bash
 kaizen-agentic status
 cat CLAUDE.md  # Detailed info
-```
+```

docs/FEEDBACK.md

@@ -0,0 +1,41 @@
+# Feedback
+
+How to share bugs, ideas, and adoption experience for kaizen-agentic.
+
+## Quick channels
+
+| Channel | Use for |
+|---------|---------|
+| **Gitea Issues** | Bugs, features, general feedback (templates below) |
+| **`kaizen-agentic feedback`** | Print links and template guidance from the CLI |
+| **Pull requests** | Code and agent-definition contributions (see CONTRIBUTING.md) |
+| **State Hub messages** | Cross-repo coordination between custodian agents (advanced) |
+
+## Gitea issue templates
+
+Choose a template when opening a new issue:
+
+- **Bug report** — reproducible defects
+- **Feature request** — enhancements with proposed scope
+- **General feedback** — experience and adoption notes
+
+Repository: [coulomb/kaizen-agentic](https://gitea.coulomb.social/coulomb/kaizen-agentic/issues)
+
+## CLI
+
+```bash
+kaizen-agentic feedback          # human-readable channel list
+kaizen-agentic feedback --json   # machine-readable for tooling
+```
+
+## What helps us most
+
+- Python version and `kaizen-agentic --version`
+- Minimal reproduction steps for bugs
+- Which agents you used and whether memory/metrics were enabled
+- For integration issues: whether artifact-store, Helix Forge, or activity-core is involved
+
+## Privacy
+
+Do not include secrets, tokens, or private project content in public issues. Redact
+`.kaizen/` memory contents unless you intentionally share sanitized examples.

docs/GETTING_STARTED.md

@@ -57,16 +57,22 @@ make install-global
 # CLI available from any directory
 ```
 
-**Option D: From PyPI (Coming Soon)**
+**Option D: From Gitea PyPI (v1.1.0+)**
 
 ```bash
-# Will be available once v1.0.0 is published
-pip install kaizen-agentic
-# or
-pipx install kaizen-agentic  # Recommended for global CLI tools
+export GITEA_PACKAGE_USER=<gitea-user>
+export GITEA_PACKAGE_TOKEN=<package-token>
+
+pip install kaizen-agentic \
+  --extra-index-url "https://${GITEA_PACKAGE_USER}:${GITEA_PACKAGE_TOKEN}@gitea.coulomb.social/api/packages/coulomb/pypi/simple/"
+
+# or global CLI via pipx
+pipx install kaizen-agentic \
+  --pip-args="--extra-index-url https://${GITEA_PACKAGE_USER}:${GITEA_PACKAGE_TOKEN}@gitea.coulomb.social/api/packages/coulomb/pypi/simple/"
 ```
 
-> **📦 Release Status**: v1.0.0 is ready for publication. Use `make install-global` for system-wide availability.
+> **📦 Registry**: Published on the Coulomb Gitea PyPI registry. Dependencies resolve
+> from public PyPI via `--extra-index-url`. See [PACKAGE_RELEASE.md](PACKAGE_RELEASE.md).
 
 ### 2. Verify Installation
 
@@ -265,7 +271,9 @@ jobs:
       - uses: actions/setup-python@v4
         with:
           python-version: '3.8'
-      - run: pip install kaizen-agentic
+      - run: >-
+          pip install kaizen-agentic
+          --extra-index-url "https://${{ secrets.GITEA_PACKAGE_USER }}:${{ secrets.GITEA_PACKAGE_TOKEN }}@gitea.coulomb.social/api/packages/coulomb/pypi/simple/"
       - run: kaizen-agentic validate
 ```
 
@@ -405,7 +413,8 @@ kaizen-agentic status
 # New team member setup
 git clone project-repo
 cd project-repo
-pip install kaizen-agentic  # or add to requirements
+# see Option D for GITEA_PACKAGE_USER / GITEA_PACKAGE_TOKEN and --extra-index-url
+pip install kaizen-agentic
 kaizen-agentic status       # See what agents are used
 kaizen-agentic validate     # Verify everything works
 
@@ -419,12 +428,16 @@ cat CLAUDE.md
 
 **"Command not found: kaizen-agentic"**
 ```bash
-# Install the package
-pip install kaizen-agentic
+# Install from Gitea PyPI (same credentials as Option D)
+export GITEA_PACKAGE_USER=<gitea-user>
+export GITEA_PACKAGE_TOKEN=<package-token>
+pip install kaizen-agentic \
+  --extra-index-url "https://${GITEA_PACKAGE_USER}:${GITEA_PACKAGE_TOKEN}@gitea.coulomb.social/api/packages/coulomb/pypi/simple/"
 
 # Or if using virtual env:
 source .venv/bin/activate
-pip install kaizen-agentic
+pip install kaizen-agentic \
+  --extra-index-url "https://${GITEA_PACKAGE_USER}:${GITEA_PACKAGE_TOKEN}@gitea.coulomb.social/api/packages/coulomb/pypi/simple/"
 ```
 
 **"No agents directory found"**
@@ -463,4 +476,4 @@ Once you have agents installed:
 4. **Share with team**: Document which agents your project uses
 5. **Contribute back**: Report issues and suggest improvements
 
-The key insight is that **you don't need the Makefile targets to use agents effectively** - the `kaizen-agentic` CLI provides all the functionality you need. The Makefile targets are just convenient shortcuts for projects that have them.
+The key insight is that **you don't need the Makefile targets to use agents effectively** - the `kaizen-agentic` CLI provides all the functionality you need. The Makefile targets are just convenient shortcuts for projects that have them.

docs/HELLO_WORLD_TUTORIAL.md

@@ -9,10 +9,18 @@ This step-by-step tutorial will guide you through creating your first project wi
 
 ## Step 1: Install Kaizen Agentic
 
+From the Coulomb Gitea PyPI registry (dependencies resolve from public PyPI):
+
 ```bash
-pip install kaizen-agentic
+export GITEA_PACKAGE_USER=<gitea-user>
+export GITEA_PACKAGE_TOKEN=<package-token>
+
+pip install kaizen-agentic \
+  --extra-index-url "https://${GITEA_PACKAGE_USER}:${GITEA_PACKAGE_TOKEN}@gitea.coulomb.social/api/packages/coulomb/pypi/simple/"
 ```
 
+See [PACKAGE_RELEASE.md](PACKAGE_RELEASE.md) for pipx and release details.
+
 Verify the installation:
 
 ```bash
@@ -235,7 +243,11 @@ kaizen-agentic status
 
 **"kaizen-agentic: command not found"**
 ```bash
-pip install kaizen-agentic
+# Same install as Step 1 (Gitea extra index — see PACKAGE_RELEASE.md)
+export GITEA_PACKAGE_USER=<gitea-user>
+export GITEA_PACKAGE_TOKEN=<package-token>
+pip install kaizen-agentic \
+  --extra-index-url "https://${GITEA_PACKAGE_USER}:${GITEA_PACKAGE_TOKEN}@gitea.coulomb.social/api/packages/coulomb/pypi/simple/"
 ```
 
 **"make: command not found"**
@@ -267,4 +279,4 @@ make test
 - ✅ AI agents for development assistance
 - ✅ Make-based development commands
 
-You're now ready to build amazing Python projects with AI agent assistance! 🚀
+You're now ready to build amazing Python projects with AI agent assistance! 🚀

docs/INTEGRATION_PATTERNS.md

@@ -1,401 +1,158 @@
-# Integration Patterns for Existing Projects
+# Integration Patterns
 
-This guide documents proven patterns for integrating Kaizen Agentic agents into existing projects that already have agent systems.
+How kaizen-agentic composes with ecosystem repos **by contract** — no merged
+codebases, no duplicated capabilities.
 
-## Overview
+Reference: [wiki/EcosystemIntegration.md](../wiki/EcosystemIntegration.md),
+[KAIZEN-WP-0004](../workplans/kaizen-agentic-WP-0004-ecosystem-integration.md).
 
-When introducing Kaizen agents to existing projects, you'll encounter various scenarios that require different integration approaches. This guide provides tested patterns and strategies.
+---
 
-## Integration Scenarios
+## Pattern 1 — Helix Forge correlation (agentic-resources)
 
-### Scenario 1: Clean Integration (No Existing Agents)
+**Problem:** Project metrics and fleet session metrics answer different questions.
 
-**When to use**: Project has no existing agent systems.
+**Contract:** Optional `helix_session_uid` on ADR-004 execution records.
+
+| kaizen-agentic | agentic-resources |
+|----------------|-------------------|
+| `metrics record` at session close | Helix capture → digest store |
+| `metrics correlate <uid>` read-only lookup | `Store.get_digest(session_uid)` |
+| `HELIX_SESSION_UID` env auto-merge | `Session.session_uid` |
+
+**Docs:** [integrations/helix-forge-correlation.md](integrations/helix-forge-correlation.md)
+
+**Boundary:** kaizen-agentic does not ingest session JSONL.
+
+---
+
+## Pattern 2 — activity-core triggers
+
+**Problem:** Recurring kaizen checks need scheduling without custom cron in this repo.
+
+**Contract:** ActivityDefinition markdown files declare triggers + actions that
+invoke kaizen-agentic CLI commands.
+
+| Definition | Trigger | CLI command |
+|------------|---------|-------------|
+| [weekly-metrics-optimize](integrations/activity-definitions/weekly-metrics-optimize.md) | Cron Mon 08:00 | `metrics optimize` |
+| [post-install-metrics-scaffold](integrations/activity-definitions/post-install-metrics-scaffold.md) | `kaizen.agent.installed` | `memory init` validation |
+| [low-success-rate-review](integrations/activity-definitions/low-success-rate-review.md) | `kaizen.metrics.recorded` | `metrics record --emit-event` |
+
+**Activation handoff (activity-core owners):**
+
+1. **Copy definitions** from kaizen-agentic:
+   `docs/integrations/activity-definitions/*.md` → activity-core
+   `activity-definitions/kaizen-agentic/` (or org-equivalent path per ACT-ADR-002).
+2. **Register in activity-core index** — ensure each definition slug appears in the
+   activity-core catalog consumed by the resolver.
+3. **Run sync** in activity-core: `make sync-activity-definitions` (or repo-equivalent).
+4. **Wire triggers** — map cron / NATS subjects (`kaizen.agent.installed`,
+   `kaizen.metrics.recorded`) to the documented CLI invocations.
+5. **Enable gradually** — set `enabled: true` per definition after a manual smoke test
+   against a repo with `.kaizen/metrics/` populated.
+6. **Verify credentials** — scheduled runs need `kaizen-agentic` on PATH and any
+   Gitea PyPI extra index if the runner installs from registry (see PACKAGE_RELEASE.md).
+
+**kaizen-agentic maintainer checklist:**
+
+- [ ] Three definition files committed under `docs/integrations/activity-definitions/`
+- [ ] activity-core PR or issue opened to register definitions
+- [ ] Smoke test commands documented below pass on a pilot repo
+
+**Smoke test (manual):**
 
-**Pattern**: Direct installation
 ```bash
-kaizen-agentic init . --agents keepaTodofile,keepaChangelog,tdd-workflow
+# Against a repo with populated metrics
+cd /path/to/project-with-kaizen
+kaizen-agentic metrics list
+kaizen-agentic metrics optimize
+# Verify analysis.json written
+test -f .kaizen/metrics/optimizer/analysis.json && echo OK
 ```
 
-**Benefits**:
-- Straightforward setup
-- No conflicts to resolve
-- Full Kaizen agent functionality
+**Boundary:** kaizen-agentic does not run Temporal schedules.
 
-### Scenario 2: Claude Code Integration
+### Scheduled agent execution (WP-0006, ADR-005)
 
-**When to use**: Project already uses Claude Code with CLAUDE.md.
+Beyond the metrics-only definitions above, agents themselves run on a cadence
+against a **preselected repo roster**. The roster combines three sources:
+
+| Source | Purpose |
+|--------|---------|
+| State Hub `GET /repos/` | Canonical slug list + `host_paths` |
+| Repo opt-in: `.kaizen/schedule.yml` exists with `version` set | Per-repo enablement |
+| Optional hub flag `kaizen_schedule_enabled: true` (future) | Operator override |
+
+A repo is **schedule-eligible** when it is registered with reachable
+`host_paths` **and** carries a valid `.kaizen/schedule.yml`. The activity-core
+resolver `discover_kaizen_scheduled_repos` intersects these and emits
+`context.scheduled_runs` (one entry per `(repo, agent)`); definitions `for_each`
+over that output.
+
+| Definition | Trigger | Agent | Prepare command |
+|------------|---------|-------|-----------------|
+| [weekly-coach-orientation](integrations/activity-definitions/weekly-coach-orientation.md) | Cron Mon 09:00 | `coach` | `schedule prepare coach` |
+| [weekly-optimization-review](integrations/activity-definitions/weekly-optimization-review.md) | Cron Mon 10:00 | `optimization` | `schedule prepare optimization` |
+
+**Listing schedule-eligible repos** (operator, no activity-core code):
 
-**Pattern**: Respectful coexistence
 ```bash
-# 1. Detect existing setup
-kaizen-agentic detect
-
-# 2. Install compatible agents
-kaizen-agentic install keepaTodofile keepaChangelog
-
-# 3. Update CLAUDE.md with new agent references
+# In each candidate repo on a host listed in state-hub host_paths:
+kaizen-agentic schedule validate && kaizen-agentic schedule list
 ```
 
-**Considerations**:
-- Preserve existing CLAUDE.md content
-- Add Kaizen agent references to existing documentation
-- Maintain Claude Code workflow compatibility
+**Design docs (no state-hub / activity-core code in this repo):**
 
-### Scenario 3: Custom Agent Replacement
+- [schedule-schema.md](integrations/schedule-schema.md) — `.kaizen/schedule.yml`
+- [state-hub-roster-fields.md](integrations/state-hub-roster-fields.md) — hub fields/filters
+- [discover-kaizen-scheduled-repos.md](integrations/discover-kaizen-scheduled-repos.md) — resolver spec
+- [kaizen-schedule-prepared-event.md](integrations/kaizen-schedule-prepared-event.md) — event payload
 
-**When to use**: Project has custom agents that overlap with Kaizen functionality.
+**Boundary:** kaizen-agentic declares and prepares; activity-core schedules;
+state-hub owns the roster.
+
+---
+
+## Pattern 3 — artifact-store evidence retention
+
+**Problem:** Optimizer outputs need durable, attributable retention beyond local disk.
+
+**Contract:** `metrics publish` registers `analysis.json` + `recommendations.jsonl`
+as an artifact package with `retention_class: raw-evidence`.
 
-**Pattern**: Gradual migration with backup
 ```bash
-# 1. Analyze existing agents
-kaizen-agentic detect --detailed
-
-# 2. Create migration plan
-kaizen-agentic migrate --dry-run
-
-# 3. Execute migration with backup
-kaizen-agentic migrate
+export ARTIFACTSTORE_API_URL=http://127.0.0.1:8000
+export ARTIFACTSTORE_API_TOKEN=<token>
+kaizen-agentic metrics optimize
+kaizen-agentic metrics publish --target .
 ```
 
-**Steps**:
-1. **Backup** existing agents
-2. **Map** custom agents to Kaizen equivalents
-3. **Migrate** functionality to extensions
-4. **Test** new agent workflow
-5. **Archive** old agents after verification
+**Manifest:** [integrations/optimizer-artifact-manifest.md](integrations/optimizer-artifact-manifest.md)
 
-### Scenario 4: Hybrid Coexistence
+**Boundary:** Publish is optional; local `.kaizen/metrics/optimizer/` remains canonical.
 
-**When to use**: Project has essential custom agents that cannot be replaced.
+---
 
-**Pattern**: Namespace separation
-```bash
-# 1. Install Kaizen agents in parallel
-kaizen-agentic install keepaTodofile --target agents/kaizen/
+## Pattern 4 — Canon and knowledge (stretch)
 
-# 2. Keep custom agents in separate directory
-# agents/custom/todo_manager.py
-# agents/kaizen/agent-keepaTodofile.md
+Design-only paths for info-tech-canon and kontextual-engine:
 
-# 3. Create integration extensions
-kaizen-agentic extensions create custom-integration keepaTodofile
-```
+- [integrations/canon-template-mapping.md](integrations/canon-template-mapping.md)
+- [integrations/briefs/tdd-workflow-canon-brief.md](integrations/briefs/tdd-workflow-canon-brief.md)
+- [integrations/kontextual-wiki-ingestion-spike.md](integrations/kontextual-wiki-ingestion-spike.md)
 
-**Directory Structure**:
-```
-project/
-├── agents/
-│   ├── custom/           # Existing custom agents
-│   │   ├── todo_manager.py
-│   │   └── code_reviewer.py
-│   └── kaizen/           # Kaizen agents
-│       ├── agent-keepaTodofile.md
-│       └── agent-code-refactoring.md
-├── .kaizen/
-│   └── extensions/       # Integration extensions
-└── CLAUDE.md             # Updated configuration
-```
+No runtime dependency in WP-0004.
 
-### Scenario 5: Extension-Based Integration
+---
 
-**When to use**: Custom agents have unique functionality that should be preserved.
+## Environment variables
 
-**Pattern**: Extend Kaizen agents with custom functionality
-```bash
-# 1. Create project-specific extension
-kaizen-agentic extensions create project-todo keepaTodofile \
-  --description "TODO manager with custom workflow integration"
-
-# 2. Configure custom behavior
-# Edit .kaizen/extensions/project-todo/extension.yml
-
-# 3. Migrate custom logic to extension
-```
-
-**Extension Configuration Example**:
-```yaml
-name: project-todo
-base_agent: keepaTodofile
-extension_type: functional_extension
-description: "TODO manager with custom workflow integration"
-
-configuration:
-  custom_instructions: |
-    Follow our project-specific TODO format:
-    - Use JIRA ticket references
-    - Include priority levels (P0-P3)
-    - Auto-assign based on component
-
-custom_commands:
-  create-epic: "Create epic-level TODO items"
-  sync-jira: "Synchronize with JIRA tickets"
-  priority-report: "Generate priority-based reports"
-
-environment_overrides:
-  JIRA_URL: "https://company.atlassian.net"
-  TODO_FORMAT: "custom"
-```
-
-## Conflict Resolution Patterns
-
-### Name Conflicts
-
-**Problem**: Multiple agents with the same name.
-
-**Pattern**: Rename with suffix
-```bash
-# Automatic resolution
-todo_manager -> todo_manager_custom
-keepaTodofile -> keepaTodofile (Kaizen agent)
-```
-
-**Implementation**:
-- Add `_custom` suffix to project-specific agents
-- Update references in scripts and documentation
-- Create aliases for backward compatibility
-
-### Functional Overlaps
-
-**Problem**: Multiple agents perform similar functions.
-
-**Pattern**: Choose primary, extend secondary
-```bash
-# Primary: Kaizen agent (standardized)
-# Secondary: Custom agent -> extension
-
-# Example: Both have TODO management
-# Decision: Use keepaTodofile as primary
-#           Convert custom logic to extension
-```
-
-**Decision Matrix**:
-| Factor | Choose Kaizen | Choose Custom | Create Extension |
-|--------|---------------|---------------|------------------|
-| Standard functionality | ✅ | ❌ | ✅ |
-| Custom business logic | ❌ | ✅ | ✅ |
-| Maintenance burden | ✅ | ❌ | ⚠️ |
-| Team familiarity | ⚠️ | ✅ | ✅ |
-
-### Integration Order
-
-**Pattern**: Infrastructure first, features last
-1. **Infrastructure agents** (setupRepository, tooling-optimization)
-2. **Core functionality** (keepaTodofile, keepaChangelog)
-3. **Development process** (tdd-workflow, code-refactoring)
-4. **Specialized features** (testing-efficiency, datamodel-optimization)
-
-## Project Structure Respect Patterns
-
-### Existing Directory Structures
-
-**Pattern**: Adaptive installation
-```bash
-# Respect existing structure
-project/
-├── tools/agents/         # Existing agent directory
-├── scripts/             # Existing automation
-└── docs/               # Existing documentation
-
-# Kaizen adaptation
-kaizen-agentic install --target tools/agents/ keepaTodofile
-# Creates: tools/agents/agent-keepaTodofile.md
-```
-
-### Configuration File Integration
-
-**Pattern**: Merge, don't replace
-```bash
-# Before
-CLAUDE.md              # Existing Claude config
-project-config.yml     # Existing project config
-
-# After (merged)
-CLAUDE.md              # Updated with Kaizen agents
-project-config.yml     # Preserved
-.kaizen/extensions.yml # New Kaizen-specific config
-```
-
-### Build System Integration
-
-**Pattern**: Extend existing targets
-```makefile
-# Existing Makefile
-test:
-	pytest tests/
-
-# After Kaizen integration (extended)
-test: test-core test-agents
-	@echo "All tests completed"
-
-test-core:
-	pytest tests/
-
-test-agents:
-	kaizen-agentic validate
-
-# New Kaizen targets
-agents-status:
-	kaizen-agentic status
-
-agents-update:
-	kaizen-agentic update
-```
-
-## Safe Transition Strategies
-
-### Phased Rollout
-
-**Phase 1: Detection and Planning**
-```bash
-# Week 1: Analysis
-kaizen-agentic detect --detailed
-kaizen-agentic migrate --dry-run
-
-# Decision point: Continue or modify approach
-```
-
-**Phase 2: Infrastructure Agents**
-```bash
-# Week 2: Core infrastructure
-kaizen-agentic install setupRepository
-# Test and validate before proceeding
-```
-
-**Phase 3: Core Functionality**
-```bash
-# Week 3: Essential agents
-kaizen-agentic install keepaTodofile keepaChangelog
-# Create extensions for custom functionality
-```
-
-**Phase 4: Advanced Features**
-```bash
-# Week 4: Specialized agents
-kaizen-agentic install tdd-workflow code-refactoring
-# Full integration testing
-```
-
-### Rollback Strategy
-
-**Pattern**: Versioned backups with restore capability
-```bash
-# Before migration
-.kaizen-migration-backup-timestamp/
-├── agents/              # Original agents
-├── CLAUDE.md           # Original configuration
-└── restoration.md      # Rollback instructions
-
-# Rollback command (if needed)
-kaizen-agentic rollback --backup .kaizen-migration-backup-timestamp/
-```
-
-### Validation Gates
-
-**Pattern**: Automated validation at each phase
-```bash
-# After each phase
-kaizen-agentic validate
-make test
-make agents-status
-
-# Success criteria for proceeding:
-# ✅ All agents load without errors
-# ✅ All tests pass
-# ✅ No functionality regressions
-```
-
-## Best Practices
-
-### Communication
-
-1. **Team Notification**: Inform team before starting migration
-2. **Documentation**: Update project docs with new agent workflows
-3. **Training**: Provide team training on Kaizen agents
-4. **Gradual Adoption**: Allow team to adapt gradually
-
-### Technical
-
-1. **Backup Everything**: Create comprehensive backups
-2. **Test Thoroughly**: Validate each integration step
-3. **Monitor Impact**: Watch for performance or workflow impacts
-4. **Version Control**: Commit changes in logical phases
-
-### Maintenance
-
-1. **Regular Updates**: Keep Kaizen agents updated
-2. **Extension Maintenance**: Maintain custom extensions
-3. **Documentation Sync**: Keep docs synchronized with agent changes
-4. **Team Feedback**: Collect and act on team feedback
-
-## Troubleshooting Common Issues
-
-### Agent Conflicts
-
-**Issue**: Multiple agents trying to manage the same files.
-
-**Solution**:
-```bash
-# Identify conflicts
-kaizen-agentic detect --detailed
-
-# Resolve with namespace separation
-mkdir agents/legacy agents/kaizen
-mv agents/todo_manager.py agents/legacy/
-kaizen-agentic install --target agents/kaizen/ keepaTodofile
-```
-
-### Configuration Conflicts
-
-**Issue**: Conflicting configuration files.
-
-**Solution**:
-```bash
-# Merge configurations
-cp CLAUDE.md CLAUDE.md.backup
-kaizen-agentic install keepaTodofile
-# Manually merge CLAUDE.md.backup content
-```
-
-### Workflow Disruption
-
-**Issue**: New agents disrupt existing workflows.
-
-**Solution**:
-```bash
-# Create compatibility extensions
-kaizen-agentic extensions create workflow-compat keepaTodofile
-# Configure extension to match existing workflow
-```
-
-## Success Metrics
-
-### Technical Metrics
-- ✅ Zero agent loading errors
-- ✅ All tests passing
-- ✅ No performance regressions
-- ✅ Successful backup/restore capability
-
-### Team Metrics
-- ✅ Team adoption of new agents
-- ✅ Maintained productivity during transition
-- ✅ Positive feedback on new capabilities
-- ✅ Reduced maintenance overhead
-
-### Project Metrics
-- ✅ Improved code quality metrics
-- ✅ Better documentation coverage
-- ✅ Enhanced development workflow efficiency
-- ✅ Standardized agent ecosystem
-
-## Conclusion
-
-Successful integration of Kaizen agents into existing projects requires:
-
-1. **Careful analysis** of existing agent systems
-2. **Respectful approach** to existing project structure
-3. **Gradual migration** with proper backup strategies
-4. **Extension mechanisms** for preserving custom functionality
-5. **Team communication** and training throughout the process
-
-Follow these patterns and your integration will be smooth, reversible, and beneficial to your development workflow.
+| Variable | Used by | Purpose |
+|----------|---------|---------|
+| `HELIX_SESSION_UID` | `metrics record` | Fleet session correlation |
+| `HELIX_REPO`, `HELIX_FLAVOR` | `metrics record` | Session context |
+| `HELIX_TOKENS`, `HELIX_INFRA_OVERHEAD_SHARE` | `metrics record` | Fleet cost fields |
+| `HELIX_STORE_DB` | `metrics correlate` | Digest lookup database |
+| `ARTIFACTSTORE_API_URL` | `metrics publish` | Registry endpoint |
+| `ARTIFACTSTORE_API_TOKEN` | `metrics publish` | Write auth bearer token |

docs/PACKAGE_RELEASE.md

@@ -0,0 +1,154 @@
+# Python Package Release
+
+`kaizen-agentic` publishes as the `kaizen-agentic` Python package on the Coulomb
+Gitea PyPI registry. Public [pypi.org](https://pypi.org/) distribution is optional
+and not required for ecosystem use.
+
+## Install (consumers)
+
+Dependencies such as `pyyaml` resolve from public PyPI. Use Gitea as an extra index:
+
+```bash
+export GITEA_PACKAGE_USER=<gitea-user>
+export GITEA_PACKAGE_TOKEN=<package-token>
+
+pip install kaizen-agentic \
+  --extra-index-url "https://${GITEA_PACKAGE_USER}:${GITEA_PACKAGE_TOKEN}@gitea.coulomb.social/api/packages/coulomb/pypi/simple/"
+```
+
+Global CLI via pipx:
+
+```bash
+pipx install kaizen-agentic \
+  --pip-args="--extra-index-url https://${GITEA_PACKAGE_USER}:${GITEA_PACKAGE_TOKEN}@gitea.coulomb.social/api/packages/coulomb/pypi/simple/"
+```
+
+Do not commit tokenized index URLs. Inject credentials via environment variables or
+CI secrets.
+
+## Local Release
+
+Build and validate artifacts:
+
+```bash
+make package-check
+```
+
+Publish to the Coulomb organization registry:
+
+```bash
+TWINE_USERNAME=<gitea-user> \
+TWINE_PASSWORD=<package-token> \
+make publish-gitea
+```
+
+Package upload endpoint:
+
+```text
+https://gitea.coulomb.social/api/packages/coulomb/pypi
+```
+
+Consumer simple index:
+
+```text
+https://gitea.coulomb.social/api/packages/coulomb/pypi/simple/
+```
+
+## Gitea repository secrets (one-time)
+
+Configure in Gitea: **Repository → Settings → Actions → Secrets**.
+
+| Secret | Value |
+|--------|-------|
+| `PACKAGE_USER` | `tegwick` — Gitea username that owns the package token |
+| `PACKAGE_TOKEN` | Gitea API token named `inter-hub-pkg-rep` (`write:package`) |
+
+Token custody (OpenBao):
+
+```text
+platform/data/operators/inter-hub/package-management
+  → field: inter-hub-pkg-rep
+```
+
+Paste the **plaintext** token into the Gitea secret UI. `inter-hub-pkg-rep` is the
+token name in Gitea, not a username.
+
+Gitea rejects secret names prefixed with `GITEA_` — use `PACKAGE_USER` / `PACKAGE_TOKEN`
+(not `GITEA_PACKAGE_USER`). Workflows use `runs-on: haskelseed` and native `git clone`
+(no GitHub Marketplace actions).
+
+The publish workflow fails at the upload step when either secret is missing or
+invalid. Do not commit tokens to the repository.
+
+**Smoke-test (2026-06-16):** `workflow_dispatch` run #3042 authenticated successfully
+(`409 Conflict` on re-upload of `1.1.0` — expected). Root causes of earlier `401`s:
+wrong token (`GITEA_API_TOKEN` ≠ package token), wrong username (`inter-hub-pkg-rep`
+is a token name), and a stale org-level secret. Build uses `.build-venv` (PEP 668).
+
+Verify secrets without cutting a release:
+
+1. Open **Actions → Publish Python package → Run workflow** (`workflow_dispatch`),
+   or dispatch via API:
+   `POST /api/v1/repos/coulomb/kaizen-agentic/actions/workflows/publish-python-package.yml/dispatches`
+   with body `{"ref":"main"}`
+2. Confirm the run completes and `twine upload` succeeds
+3. Optional: `pip install kaizen-agentic==<version> --extra-index-url ...`
+
+The publish job uses an isolated `.build-venv` on the runner (PEP 668 safe).
+
+## Pre-tag release checklist
+
+Before `git tag vX.Y.Z && git push origin vX.Y.Z`:
+
+- [ ] `make release-check` passes (tests, flake8, version consistency, agent parity)
+- [ ] `make package-check` builds and validates `dist/*`
+- [ ] `CHANGELOG.md` has a dated `[X.Y.Z]` section matching `pyproject.toml`
+- [ ] `PACKAGE_USER` and `PACKAGE_TOKEN` secrets are set
+- [ ] Publish workflow smoke-tested via `workflow_dispatch` (or prior tag release)
+- [ ] `make agents-sync-package` run if `agents/` changed since last release
+
+## Gitea Actions Release
+
+The `.gitea/workflows/publish-python-package.yml` workflow publishes on tags
+matching `v*`.
+
+Example:
+
+```bash
+git tag v1.2.0
+git push origin v1.2.0
+```
+
+## Public PyPI (optional)
+
+When pypi.org credentials are configured (`~/.pypirc` or `TWINE_PASSWORD` API
+token with `TWINE_USERNAME=__token__`):
+
+```bash
+make release-publish
+python -m twine upload dist/*
+```
+
+## Scheduled-run runner prerequisites (WP-0006)
+
+A runner that executes a scheduled kaizen agent task (fired by activity-core)
+needs:
+
+- **`kaizen-agentic` on PATH** — `pip install kaizen-agentic` (or `pipx install
+  kaizen-agentic`) using the Gitea PyPI extra index when installing from the
+  internal registry:
+  ```bash
+  pip install kaizen-agentic \
+    --extra-index-url https://gitea.coulomb.social/api/packages/coulomb/pypi/simple/
+  ```
+- **Repo checkout reachable** at the `host_paths[<host>]` registered in State
+  Hub, with a valid `.kaizen/schedule.yml` (`kaizen-agentic schedule validate`).
+- **No State Hub required for `prepare`** — `schedule prepare` reads local
+  `.kaizen/` state only. The hub is needed by the *resolver* (activity-core),
+  not by the prepared session.
+
+**Enabling a definition** (activity-core operator): keep the kaizen definitions
+at `enabled: false` until a manual smoke test passes (see
+[INTEGRATION_PATTERNS.md Pattern 2](INTEGRATION_PATTERNS.md) and the
+[activity-core handoff checklist](integrations/activity-core-handoff-wp0006.md)),
+then flip one definition to `enabled: true` in staging before fleet-wide enable.

docs/TELEMETRY.md

@@ -0,0 +1,49 @@
+# Telemetry and Agent Effectiveness Tracking
+
+WP-0001 T04 design — aligned with ADR-004 and WP-0004 ecosystem integration.
+
+## Two layers (do not merge)
+
+| Layer | Question | Mechanism |
+|-------|----------|-----------|
+| **Project** | How is agent *X* performing in *this repo*? | `kaizen-agentic metrics record` → `.kaizen/metrics/` |
+| **Fleet** | How are coding sessions performing *across repos*? | agentic-resources Helix Forge |
+
+kaizen-agentic **does not** ship a parallel session transcript ingestion pipeline.
+
+## Project telemetry (implemented)
+
+Memory-enabled agents record per-session outcomes at close:
+
+```bash
+kaizen-agentic metrics record <agent> --success --time <s> --quality <0-1>
+kaizen-agentic metrics record <agent> --success --time <s> --quality <0-1> --emit-event
+kaizen-agentic metrics optimize [agent]
+kaizen-agentic memory brief <agent>    # includes Performance Summary
+```
+
+Optional fleet correlation via `HELIX_SESSION_UID` (see
+[integrations/helix-forge-correlation.md](integrations/helix-forge-correlation.md)).
+
+## Fleet telemetry (agentic-resources)
+
+Helix Forge owns session capture, digest storage, baselines, and weekly retro.
+kaizen-agentic consumes correlation fields only.
+
+## CLI install / usage analytics (future)
+
+Potential v1.1 additions (not yet implemented):
+
+- Opt-in anonymous counters on `install` / `memory init` (no PII, no project paths)
+- Aggregate effectiveness reports via `metrics list` across a monorepo checkout
+
+## tele-mcp evaluation (deferred)
+
+[tele-mcp](https://gitea.coulomb.social/coulomb/tele-mcp) is a candidate MCP adapter
+for IDE-level telemetry (WP-0001 note). Assess before depending on it. Project and
+fleet layers above satisfy INTENT's "measurable agents" requirement without tele-mcp.
+
+## Feedback loop
+
+User experience feedback uses [FEEDBACK.md](FEEDBACK.md) and Gitea issue templates —
+separate from execution metrics.

docs/adr/ADR-001-workplan-convention.md

@@ -0,0 +1,57 @@
+---
+id: ADR-001
+title: Workplan Convention
+status: accepted
+date: "2026-03-18"
+---
+
+# ADR-001 — Workplan Convention
+
+## Status
+
+Accepted
+
+## Context
+
+kaizen-agentic needs a way to track planned work that is version-controlled,
+visible to the state-hub, and authoritative when the two diverge.
+
+## Decision
+
+Work items originate as Markdown files in `workplans/` **before** being
+registered in the state-hub DB. The file is always authoritative; the DB is
+a read/query model derived from it.
+
+**File naming:** `workplans/kaizen-agentic-WP-NNNN-<slug>.md`
+**ID prefix:** `KAIZEN-WP`
+
+### Required YAML frontmatter
+
+```yaml
+---
+id: KAIZEN-WP-NNNN
+type: workplan
+title: "..."
+domain: custodian
+repo: kaizen-agentic
+status: active | completed | archived
+owner: kaizen-agentic
+topic_slug: custodian
+state_hub_workstream_id: <uuid>
+created: "YYYY-MM-DD"
+updated: "YYYY-MM-DD"
+---
+```
+
+### Task tracking
+
+Tasks use `- [ ]` / `- [x]` checkboxes with a `T##` code prefix. A
+`## State Hub Task IDs` table at the end of each workplan maps codes to
+DB UUIDs so status can be synced without a list_tasks lookup.
+
+## Consequences
+
+- File is the source of truth; DB drift is auto-fixable via
+  `check_repo_consistency(fix=True)`.
+- Tasks must be created in the file first, then registered in the hub.
+- C-12 warnings are expected when the DB host has not yet seen local changes.

docs/adr/ADR-002-project-memory-convention.md

@@ -0,0 +1,119 @@
+---
+id: ADR-002
+title: Project Memory Convention
+status: accepted
+date: "2026-03-18"
+---
+
+# ADR-002 — Project Memory Convention
+
+## Status
+
+Accepted
+
+## Context
+
+kaizen-agentic agents are stateless by default — each session starts from
+scratch with no knowledge of what has been tried, what worked, or what the
+project's recurring patterns are. This makes agents less useful over time
+and forces the operator to re-supply context that the agent itself
+accumulated.
+
+## Decision
+
+Each agent deployed into a project may maintain a **project-scoped memory
+file**. Memory files are written at session close and read at session start.
+
+### File location
+
+```
+<project-root>/.kaizen/agents/<agent-name>/memory.md
+```
+
+The `.kaizen/` directory is the kaizen-agentic ecosystem's project-level
+state directory, analogous to `.claude/` for Claude Code.
+
+### Memory file structure
+
+```markdown
+---
+agent: <agent-name>
+project: <project-root or slug>
+last_updated: <ISO date>
+session_count: <n>
+---
+
+## Project Context
+<!-- What this agent knows about the project it works in -->
+
+## Accumulated Findings
+<!-- Patterns, recurring issues, key decisions encountered -->
+
+## What Worked
+<!-- Approaches that produced good results in this project -->
+
+## Watch Points
+<!-- Recurring risks, traps, or areas requiring extra care -->
+
+## Open Threads
+<!-- Things noticed but not yet acted on -->
+
+## Session Log
+<!-- One-line entry per session: date · summary · outcome -->
+```
+
+### Session-start protocol (all memory-enabled agents)
+
+1. Check for `.kaizen/agents/<name>/memory.md` in the project root.
+2. If present, read it before beginning work.
+3. Acknowledge the memory in the opening brief.
+
+### Session-close protocol (all memory-enabled agents)
+
+1. Update `## Accumulated Findings`, `## What Worked`, `## Watch Points`
+   as needed.
+2. Append one line to `## Session Log`.
+3. Bump `last_updated` and `session_count`.
+
+### Agent opt-out
+
+An agent may declare `memory: disabled` in its YAML frontmatter to opt out.
+Default is enabled. Stateless utility agents (e.g. `keepaTodofile`) should
+opt out.
+
+### CLI interface
+
+```
+kaizen-agentic memory show <agent>   # Print agent memory for current project
+kaizen-agentic memory init <agent>   # Scaffold empty memory file
+kaizen-agentic memory brief <agent>  # Run coach, print orientation for agent
+kaizen-agentic memory clear <agent>  # Wipe memory (with confirmation prompt)
+```
+
+`memory init` creates the `.kaizen/agents/<name>/memory.md` file with the
+standard structure and populates the frontmatter.
+
+### Coaching meta-agent
+
+A dedicated `agent-coach.md` (category: `meta`) reads across all
+`.kaizen/agents/*/memory.md` files in a project and:
+
+- Synthesises a cross-agent brief (shared patterns, cross-domain risks)
+- Produces a new-agent orientation targeted at a specific agent about to
+  be deployed for the first time
+- Maintains its own memory covering meta-level fleet observations
+
+`kaizen-agentic memory brief <agent>` invokes the coach to produce this
+orientation.
+
+## Consequences
+
+- Agents accumulate project-specific knowledge and arrive in later sessions
+  informed rather than blank.
+- The `.kaizen/` directory should be added to `.gitignore` by default;
+  teams may choose to commit it for shared context.
+- Memory files are human-readable and can be manually edited or reviewed.
+- The coach agent provides a single synthesised view across all agent
+  memories — reducing the operator's burden of re-supplying context.
+- Agents with `memory: disabled` remain fully stateless and require no
+  `.kaizen/` setup.

docs/adr/ADR-003-protocols-artifact-convention.md

@@ -0,0 +1,116 @@
+---
+id: ADR-003
+title: Protocols Artifact Convention
+status: accepted
+date: "2026-03-18"
+---
+
+# ADR-003 — Protocols Artifact Convention
+
+## Status
+
+Accepted
+
+## Context
+
+Some agents perform structured, repeatable assessments or remediation procedures
+(e.g. sys-medic's k3s node health assessment). These procedures exist as narrative
+text embedded in agent prompts or companion documents, making them hard to discover,
+reference, version, or evolve independently of the agent prompt.
+
+Protocols are distinct from agent prompts:
+- Agent prompts shape AI behaviour
+- Protocols are procedural checklists for humans and agents to execute
+
+They need their own artifact type with a stable location and structure.
+
+## Decision
+
+### File location
+
+```
+agents/protocols/<agent-name>/<slug>.md
+```
+
+Protocols live inside the `agents/` directory alongside agent definitions,
+grouped by owning agent. The `agents/protocols/` subtree is a managed artifact
+collection — not executable code, not agent prompts.
+
+### File structure
+
+```markdown
+---
+agent: <agent-name>
+slug: <slug>
+title: <human-readable title>
+version: <semver>
+last_updated: <ISO date>
+---
+
+# <Title>
+
+## Purpose
+<!-- One paragraph: what this protocol checks or achieves -->
+
+## Scope
+<!-- What systems, components, or conditions this protocol applies to -->
+
+## Prerequisites
+<!-- What must be true before starting -->
+
+## Procedure
+
+### Step 1 — <name>
+<!-- Commands, checks, observations -->
+
+### Step 2 — <name>
+...
+
+## Interpretation
+<!-- How to read the results: what is normal, what is a warning, what requires action -->
+
+## Remediation
+<!-- Common issues and how to resolve them -->
+
+## Notes
+<!-- Version history, known limitations, related protocols -->
+```
+
+### Lifecycle
+
+- Protocols are **created** when a repeatable procedure is identified during agent work
+- Protocols are **refined** across sessions as the owning agent accumulates experience
+- Protocols are **referenced** by agent prompts using the convention:
+  *"If available, use the `<slug>` protocol at `agents/protocols/<agent-name>/<slug>.md`"*
+- Protocols are **human-readable** and can be executed without an AI agent present
+
+### Relationship to agent memory
+
+Agent memory captures *what was learned* in a project. Protocols capture *how to
+do a repeatable thing* independent of any specific project. A protocol may be
+updated based on findings across many projects, but it does not store
+project-specific state.
+
+### CLI interface
+
+```
+kaizen-agentic protocols list [agent]            # List protocols (optionally filtered by agent)
+kaizen-agentic protocols show <agent> <slug>     # Print a protocol
+```
+
+`kaizen-agentic memory init sys-medic` will scaffold the sys-medic protocol
+directory alongside the memory file when protocols exist for that agent.
+
+### README
+
+Each `agents/protocols/` directory contains a `README.md` explaining the
+convention and listing available protocols.
+
+## Consequences
+
+- Protocols are independently versioned and evolvable without touching agent prompts.
+- The `agents/protocols/` directory is part of the kaizen-agentic repo and
+  distributed alongside agent definitions.
+- Operators can view, adapt, or execute protocols without running the CLI.
+- The first protocol — sys-medic's k3s node health assessment — migrates from
+  its current location into `agents/protocols/sys-medic/k3s-node-health-assessment.md`.

docs/adr/ADR-004-project-metrics-convention.md

@@ -0,0 +1,190 @@
+---
+id: ADR-004
+title: Project Metrics Convention
+status: accepted
+date: "2026-06-16"
+---
+
+# ADR-004 — Project Metrics Convention
+
+## Status
+
+Accepted
+
+## Context
+
+`INTENT.md` requires agents to be measurable, versioned, and optimizable. The
+agency framework (ADR-002) provides **qualitative** project memory; the kaizen
+loop needs **quantitative** per-execution records.
+
+`wiki/AgentKaizenOptimizer.md` specifies `.kaizen/metrics/` storage.
+`OptimizationLoop` in `src/kaizen_agentic/optimization.py` exists but has no
+data source.
+
+Separately, `agentic-resources` (Helix Forge) captures **fleet-level** session
+metrics from coding agent transcripts. Project metrics and fleet metrics serve
+different scopes and must correlate without duplicating ingestion logic.
+
+## Decision
+
+Each agent deployed into a project may accumulate **project-scoped execution
+metrics**. Records are append-only JSONL with rolling summaries. The optimizer
+reads these files to produce evidence-based recommendations.
+
+### File locations
+
+Per-agent executions:
+
+```
+<project-root>/.kaizen/metrics/<agent-name>/
+  executions.jsonl    # append-only per-execution records
+  summary.json        # rolling aggregates (regenerated on write)
+```
+
+Optimizer outputs:
+
+```
+<project-root>/.kaizen/metrics/optimizer/
+  analysis.json           # last analysis run + input fingerprint
+  recommendations.jsonl   # append-only recommendation history
+```
+
+The `.kaizen/metrics/` tree lives alongside `.kaizen/agents/` under the same
+project-level state directory (ADR-002).
+
+### Execution record schema (minimum viable)
+
+```json
+{
+  "timestamp": "2026-06-16T12:00:00Z",
+  "agent": "tdd-workflow",
+  "session_id": "optional-uuid-or-hash",
+  "execution_time_s": 0.0,
+  "success": true,
+  "quality_score": 0.0,
+  "primary_metric": {
+    "name": "test_pass_rate",
+    "value": 1.0,
+    "target": 1.0
+  },
+  "metadata": {}
+}
+```
+
+Required fields: `timestamp`, `agent`, `success`.
+Recommended fields: `execution_time_s`, `quality_score`, `primary_metric`.
+
+### Summary schema
+
+`summary.json` is derived — never hand-edited. Regenerated on each append:
+
+```json
+{
+  "agent": "tdd-workflow",
+  "execution_count": 12,
+  "success_rate": 0.917,
+  "avg_quality_score": 0.82,
+  "avg_execution_time_s": 45.3,
+  "last_execution": "2026-06-16T12:00:00Z",
+  "trend": {
+    "success_rate": "stable",
+    "quality_score": "up"
+  }
+}
+```
+
+### Retention
+
+Default retention: **180 days** (per `wiki/AgentKaizenOptimizer.md`).
+Pruning removes aged lines from `executions.jsonl` and regenerates `summary.json`.
+Project-level override via `.kaizen/metrics/config.json` is reserved for a
+future iteration.
+
+### Session-close protocol
+
+Memory-enabled agents with declared metrics should append one execution record
+at session close:
+
+```bash
+kaizen-agentic metrics record <agent> --success --time <seconds> --quality <0-1>
+```
+
+Or pipe a full JSON record via `--json` / stdin.
+
+### CLI interface
+
+```
+kaizen-agentic metrics record <agent>   # Append execution record
+kaizen-agentic metrics show <agent>     # Summary + recent executions
+kaizen-agentic metrics list             # Agents with metrics in project
+kaizen-agentic metrics export <agent>   # Dump executions.jsonl
+kaizen-agentic metrics optimize [agent] # Run OptimizationLoop (WP-0003 Part 3)
+```
+
+`kaizen-agentic memory init <agent>` scaffolds metrics directories by default
+(`--no-metrics` to opt out).
+
+### Helix Forge correlation
+
+Kaizen-agentic **project metrics** and agentic-resources **fleet metrics**
+operate at different layers:
+
+| Layer | Scope | Owner | Typical storage |
+|-------|-------|-------|-----------------|
+| Project | Per-agent persona in one repo | kaizen-agentic | `.kaizen/metrics/` |
+| Fleet | Cross-repo coding sessions | agentic-resources | Helix Forge digest store + `measure/baselines.jsonl` |
+
+**Correlation fields** — optional on project execution records, populated when
+the session is also captured by Helix Forge:
+
+```json
+{
+  "helix_session_uid": "claude:<native-session-uuid>",
+  "repo": "kaizen-agentic",
+  "flavor": "claude",
+  "tokens": 12500,
+  "infra_overhead_share": 0.12
+}
+```
+
+Mapping from Helix Forge `session_metrics()` (agentic-resources):
+
+| Helix field | ADR-004 field |
+|-------------|---------------|
+| `digest.outcome == "success"` | `success` |
+| `digest.cost.wall_clock_s` | `execution_time_s` |
+| `tokens` (input + output) | `tokens` in metadata / top-level |
+| `infra_overhead_share` | `metadata.infra_overhead_share` |
+| `Session.session_uid` | `helix_session_uid` |
+| `Session.repo` | `repo` |
+| `Session.flavor` | `flavor` |
+
+Kaizen-agentic does **not** ingest Claude/Codex/Grok JSONL transcripts.
+Correlation is **link-by-reference**: project metrics may cite a Helix session
+UID; fleet analytics remain owned by agentic-resources.
+
+WP-0004 defines the integration contract and optional sync tooling.
+
+### Coach and memory integration
+
+`kaizen-agentic memory brief <agent>` includes a `## Performance Summary`
+section when `summary.json` exists (WP-0003 Part 4). Qualitative memory
+(ADR-002) and quantitative metrics (this ADR) are complementary views of the
+same agent's project history.
+
+## Consequences
+
+- Agents can be measured per project without a central telemetry platform.
+- `OptimizationLoop` has a defined data source for recommendations.
+- Fleet session analytics stay in agentic-resources; no duplicate ingestion.
+- `.kaizen/metrics/` should default to `.gitignore` (same policy as memory).
+- WP-0003 implements `MetricsStore` and CLI against this convention.
+- WP-0004 wires ecosystem services (activity-core, artifact-store, Helix Forge).
+
+## Related Documents
+
+- [ADR-002: Project Memory Convention](ADR-002-project-memory-convention.md)
+- [wiki/EcosystemIntegration.md](../../wiki/EcosystemIntegration.md)
+- [agentic-resources session schema](https://github.com/coulomb/agentic-resources) — `session_memory/core/schema.py`
+- [KAIZEN-WP-0003](../../workplans/kaizen-agentic-WP-0003-measurement-loop.md)
+- [KAIZEN-WP-0004](../../workplans/kaizen-agentic-WP-0004-ecosystem-integration.md)

docs/adr/ADR-005-scheduled-agent-execution.md

@@ -0,0 +1,150 @@
+---
+id: ADR-005
+title: Scheduled Agent Execution Convention
+status: accepted
+date: "2026-06-17"
+---
+
+# ADR-005 — Scheduled Agent Execution Convention
+
+## Status
+
+Accepted
+
+## Context
+
+Kaizen agents are markdown instruction sets invoked in coding-agent sessions.
+ADR-004 added project-scoped metrics; WP-0004 committed three metrics-focused
+`ActivityDefinition` drafts (`enabled: false`). What is still missing is a way to
+run **agents themselves** — not just the metrics optimizer — on a **regular
+cadence** against a **preselected set of repos**, without kaizen-agentic owning
+Temporal workers, cron, or an LLM runtime.
+
+The ecosystem already separates concerns:
+
+- **activity-core** owns scheduling (cron/event → task creation).
+- **state-hub** owns the canonical repo roster and `host_paths`.
+- **kaizen-agentic** owns the agents, project memory, and metrics.
+
+A scheduled agent run therefore needs a contract that crosses these repos
+without merging them.
+
+## Decision
+
+Introduce a **repo-local schedule manifest** and a **prepare** step. The
+end-to-end flow:
+
+```
+activity-core cron
+  → context resolver (roster ∩ repos with schedule.yml)
+  → task per (repo, agent)
+  → coding-agent session runs `kaizen-agentic schedule prepare <agent>`
+  → session executes the agent instructions in that repo
+```
+
+kaizen-agentic's responsibilities are exactly two: **declare** the schedule
+(`.kaizen/schedule.yml`) and **prepare** an orientation bundle for a run. It
+does **not** fire cron, create tasks, or invoke Claude.
+
+### 1. Schedule manifest — `.kaizen/schedule.yml`
+
+A repo opts into fleet scheduling by committing this file:
+
+```yaml
+version: "1"
+timezone: Europe/Berlin
+agents:
+  coach:
+    cadence: weekly
+    cron: "0 9 * * 1"      # optional override; default from ActivityDefinition
+    enabled: true
+  optimization:
+    cadence: weekly
+    cron: "0 10 * * 1"
+    enabled: true
+  tdd-workflow:
+    cadence: monthly
+    enabled: false
+```
+
+**Schema:**
+
+| Key | Required | Type | Notes |
+|-----|----------|------|-------|
+| `version` | yes | string | Must be `"1"` |
+| `timezone` | no | string | IANA tz; default supplied by ActivityDefinition |
+| `agents` | yes | mapping | `agent-name → settings` |
+| `agents.<name>.cadence` | yes | enum | `daily` \| `weekly` \| `monthly` |
+| `agents.<name>.cron` | no | string | 5-field cron; overrides cadence default |
+| `agents.<name>.enabled` | no | bool | Default `true` |
+
+**Validation rules** (`kaizen-agentic schedule validate`):
+
+- `version` must equal `"1"`.
+- Every agent key must be an installed or packaged agent name.
+- `cadence` must be one of the allowed values.
+- Duplicate agent entries are rejected.
+
+### 2. Roster (preselected repos)
+
+A repo is **schedule-eligible** when **all** of:
+
+1. It is a registered repo in state-hub (`GET /repos/`) with reachable
+   `host_paths`.
+2. It contains a valid `.kaizen/schedule.yml`.
+3. (Optional, future) it carries a `kaizen_schedule_enabled: true` hub flag.
+
+The resolver `discover_kaizen_scheduled_repos` (specified in
+`docs/integrations/discover-kaizen-scheduled-repos.md`, implemented in
+activity-core) intersects these sources and emits `context.scheduled_runs`.
+
+### 3. Prepare bundle — `schedule prepare <agent>`
+
+Assembles, from **local `.kaizen/` state only** (offline-safe):
+
+- The agent prompt (`agents/agent-<name>.md`, installed or packaged).
+- Project memory (`.kaizen/agents/<name>/memory.md`) when present.
+- Metrics summary (`.kaizen/metrics/<name>/summary.json`) when present.
+- Repo pointers (`SCOPE.md`, `workplans/`) when present.
+- Suggested session-close commands (`metrics record`, memory update).
+
+Output is `markdown` (default) or `json` (`--format json`) so activity-core can
+embed it in a task `description` or a runner can parse it.
+
+### CLI interface
+
+```
+kaizen-agentic schedule init [--target PATH] [--timezone TZ] [--force]
+kaizen-agentic schedule init --engagement <slug> [--agents A,B] [--bootstrap-cadence hourly|daily|weekly]
+kaizen-agentic schedule validate [--target PATH]
+kaizen-agentic schedule list [--target PATH] [--all]
+kaizen-agentic schedule prepare <agent> [--target PATH] [--format markdown|json]
+```
+
+## Boundaries
+
+- **No scheduling code** in kaizen-agentic. Cron and task creation belong to
+  activity-core; the roster query belongs to state-hub.
+- **No LLM invocation.** `prepare` produces a runner-agnostic bundle; a human or
+  automated coding-agent session executes it.
+- **State-hub schema changes** (roster opt-in flag) are designed here but
+  implemented in `the-custodian` (repo boundary).
+
+## Consequences
+
+- Operators declare per-repo schedules and a fleet roster without tribal
+  knowledge.
+- activity-core can fire recurring tasks referencing `schedule prepare`.
+- A scheduled session opens with full orientation (prompt + memory + metrics).
+- The existing `weekly-metrics-optimize` definition (ADR-004 / WP-0004) remains
+  complementary; an `optimization` agent run may chain `schedule prepare
+  optimization` then `metrics optimize`.
+
+## Related Documents
+
+- [ADR-002: Project Memory Convention](ADR-002-project-memory-convention.md)
+- [ADR-004: Project Metrics Convention](ADR-004-project-metrics-convention.md)
+- [docs/integrations/schedule-schema.md](../integrations/schedule-schema.md)
+- [docs/integrations/discover-kaizen-scheduled-repos.md](../integrations/discover-kaizen-scheduled-repos.md)
+- [docs/agency-framework.md](../agency-framework.md)
+- [KAIZEN-WP-0006](../../workplans/kaizen-agentic-WP-0006-scheduled-agent-execution.md)

docs/adr/ADR-006-customer-engagement-convention.md

@@ -0,0 +1,74 @@
+# ADR-006: Customer Engagement Convention
+
+**Status:** accepted
+**Date:** 2026-06-18
+**Deciders:** kaizen-agentic maintainers (supplier)
+**Customer reference:** coulomb-loop / LOOP-WP-0000
+
+## Context
+
+Coulomb's `coulomb-loop` engagement introduced a **customer/supplier split**:
+the customer repo holds contracts and operations; `kaizen-agentic` ships agents
+and CLI; target repos hold `.kaizen/` runtime state. We need a durable convention
+so the second customer engagement reuses ≤50% of coulomb-loop setup effort.
+
+## Decision
+
+### 1. Repo roles
+
+| Role | Owns |
+|------|------|
+| **Customer engagement repo** | INTENT, workplans, ADRs, rosters, ActivityDefinition copies, loop health |
+| **Supplier (kaizen-agentic)** | Agent prompts, CLI, integration specs, playbook, supplier workplans |
+| **Target repos** | `.kaizen/schedule.yml`, `agents/`, `metrics/`, memory |
+| **activity-core** | Cron/event orchestration, resolvers, task creation |
+
+### 2. `.kaizen/` placement
+
+Project-scoped kaizen state **never** lives in the customer engagement repo.
+It lives only in repos where agents execute (fleet pilots).
+
+### 3. Supplier CLI engagement mode
+
+```bash
+kaizen-agentic schedule init --engagement <customer-slug> \
+  --agents coach,optimization --bootstrap-cadence hourly
+```
+
+Writes bootstrap schedule with engagement comment and hourly cron presets.
+See [customer-engagement-playbook.md](../integrations/customer-engagement-playbook.md).
+
+### 4. Event emission (opt-in)
+
+```bash
+kaizen-agentic metrics record <agent> --success --time <s> --quality <0-1> --emit-event
+```
+
+Publishes `kaizen.metrics.recorded` for activity-core event definitions.
+Default off for backward compatibility.
+
+### 5. Playbook lifecycle
+
+1. **Bootstrap** — customer LOOP-WP-0000; supplier KAIZEN-WP-0008 Part 1
+2. **Smoke** — hourly E2E on pilot roster (LOOP-WP-0001)
+3. **Automate** — emit-event, activity-core definitions enabled incrementally
+4. **Generalize** — supplier-notes → playbook v1; ADR-006 + layout docs
+5. **Second customer** — copy layout; swap roster and definitions
+
+### 6. ActivityDefinition ownership
+
+Bootstrap uses **customer-owned copies** (coulomb DEC-003 option A).
+Hybrid override manifest (option C) is design-only — see
+[activity-definition-override-manifest.md](../integrations/activity-definition-override-manifest.md).
+
+## Consequences
+
+- New engagements follow [customer-engagement-repo-layout.md](../integrations/customer-engagement-repo-layout.md)
+- Supplier friction is logged in customer `loops/*/supplier-notes.md` and absorbed into playbook
+- activity-core handoff requirements are documented per engagement wave
+
+## Related
+
+- coulomb-loop `docs/adr/ADR-002-customer-supplier-boundary.md`
+- [ADR-005](ADR-005-scheduled-agent-execution.md) — schedule contract
+- [KAIZEN-WP-0008](../../workplans/kaizen-agentic-WP-0008-coulomb-loop-supplier-engagement.md)

docs/agency-framework.md

@@ -0,0 +1,351 @@
+# Agency Framework
+
+kaizen-agentic is not just a library of agent instruction sets — it is an **agency**: a system where agents are deployed into projects with their own persistent memory, learn from experience, and are guided by a coaching meta-agent that distils patterns across the entire fleet.
+
+## Overview
+
+When you deploy a kaizen-agentic agent into a project, it can accumulate **project-scoped memory** — a structured file written at session close and read at session start. A **Coach** meta-agent reads across all agent memories and produces orientation briefs for newly deployed agents: what has been tried, what worked, what to watch out for.
+
+Agents arrive in a project informed, not blank.
+
+---
+
+## Project Memory
+
+### Location Convention
+
+```
+<project-root>/.kaizen/agents/<agent-name>/memory.md
+```
+
+The `.kaizen/` directory is analogous to `.claude/` — a project-level configuration and state directory owned by the kaizen-agentic ecosystem.
+
+### Memory File Structure
+
+```markdown
+---
+agent: <name>
+project: <project-root or slug>
+last_updated: <ISO date>
+session_count: <n>
+---
+
+## Project Context
+<!-- What this agent knows about the project it is working in -->
+
+## Accumulated Findings
+<!-- Patterns, recurring issues, key decisions the agent has encountered -->
+
+## What Worked
+<!-- Approaches that produced good results in this project -->
+
+## Watch Points
+<!-- Recurring risks, traps, or areas requiring extra care -->
+
+## Open Threads
+<!-- Things noticed but not yet acted on -->
+
+## Session Log
+<!-- One-line entry per session: date · summary · outcome -->
+```
+
+### Session Protocols
+
+**Session-start (all agents with `memory: enabled`):**
+
+1. Check for `.kaizen/agents/<name>/memory.md` in the project root.
+2. If present, read it before beginning work.
+3. Acknowledge the memory in the opening brief.
+
+**Session-close (all agents with `memory: enabled`):**
+
+1. Update `## Accumulated Findings`, `## What Worked`, `## Watch Points` as appropriate.
+2. Append one line to `## Session Log`: `YYYY-MM-DD · <summary> · <outcome>`.
+3. Bump `last_updated` and `session_count`.
+
+---
+
+## Agent YAML Frontmatter
+
+Each agent definition (`agents/agent-<name>.md`) includes a YAML frontmatter block:
+
+```yaml
+---
+name: <name>
+description: <one-line description>
+category: <category>
+memory: enabled   # or: disabled
+---
+```
+
+The `memory` field defaults to `enabled`. Set `memory: disabled` for agents that are stateless by design (e.g. `wisdom-encouragement`).
+
+The file name must follow `agent-<name>.md` where `<name>` equals the frontmatter
+`name`. `kaizen-agentic validate` enforces the frontmatter schema (required
+fields, known `category`, valid `memory`/`model`).
+
+### Authoring and doc sync (WP-0007)
+
+```bash
+kaizen-agentic create-agent <name> -c <category> -d "<description>"
+kaizen-agentic validate                 # schema + dependency checks
+kaizen-agentic docs generate            # refresh CLAUDE.md Installed Agents
+make agents-sync-package                # keep packaged data/agents/ in parity
+```
+
+`create-agent` writes a schema-valid skeleton; `docs generate` rewrites the
+project `## Installed Agents` section **idempotently** (use `--check` as a CI
+gate). The section is grouped by the declared frontmatter `category`.
+
+---
+
+## The Coach Meta-Agent
+
+`agents/agent-coach.md` is a **meta-agent** — it performs no domain work (coding, testing, infrastructure). Its sole purpose is synthesis and advice.
+
+### What the Coach Does
+
+- **Cross-agent synthesis**: reads all `.kaizen/agents/*/memory.md` files, identifies shared patterns, cross-domain risks, and contradictions
+- **New-agent orientation**: when briefing a specific agent, filters all existing memories for what is relevant and produces a targeted brief
+- **Fleet health overview**: summarises which agents are active, stale, or missing; flags high-session-count agents with open threads
+
+### Invoking the Coach
+
+**Via CLI (assembles raw memory context):**
+
+```bash
+kaizen-agentic memory brief <agent-name>
+```
+
+This prints a structured orientation brief. Pass the output to a Claude session with `agents/agent-coach.md` loaded for full LLM synthesis.
+
+**Directly in a Claude session:**
+
+```
+Coach, brief the sys-medic agent on this project.
+Coach, what patterns have you observed across all agents?
+```
+
+The Coach maintains its own memory at `.kaizen/agents/coach/memory.md` covering fleet-level observations over time.
+
+---
+
+## CLI Reference
+
+The `memory` command group manages project-scoped agent memory:
+
+```
+kaizen-agentic memory show <agent>      # Print agent memory for the current project
+kaizen-agentic memory init <agent>      # Scaffold an empty memory file
+kaizen-agentic memory brief <agent>     # Assemble orientation context for the coach
+kaizen-agentic memory clear <agent>     # Wipe memory (with confirmation prompt)
+```
+
+### Options
+
+`memory brief` accepts:
+- `--target / -t` — project root (default: current directory)
+- `--raw` — dump raw memory file contents without the structured header
+
+### Example Workflow
+
+```bash
+# First deployment of sys-medic into a project
+kaizen-agentic memory init sys-medic
+
+# After a few sessions, brief an incoming tdd-workflow agent
+kaizen-agentic memory brief tdd-workflow
+# → paste output into Claude with agent-coach.md loaded
+
+# Review accumulated memory for a specific agent
+kaizen-agentic memory show project-management
+```
+
+---
+
+## Protocol Runbooks
+
+Agents can reference **protocol runbooks** — structured, human-readable procedural checklists for structured assessments or remediation work. Protocols are distinct from agent prompts:
+
+- **Agent prompts** (`agents/agent-*.md`) shape AI behaviour
+- **Protocols** (`agents/protocols/<agent>/<slug>.md`) are procedural documents for humans and agents to execute
+
+### Location Convention
+
+```
+agents/protocols/
+  <agent-name>/
+    <slug>.md    ← one file per protocol
+```
+
+### Protocol Frontmatter
+
+Each protocol file has a YAML frontmatter block:
+
+```yaml
+---
+agent: <agent-name>
+slug: <slug>
+title: <human-readable title>
+version: 1.0.0
+last_updated: "<ISO date>"
+---
+```
+
+### Referencing Protocols from Agents
+
+Agents with `memory: enabled` check for relevant protocols at session start and reference them in their session-start protocol block. For example, sys-medic's session-start protocol instructs:
+
+> *"If a structured assessment is requested, check for `agents/protocols/sys-medic/k3s-node-health-assessment.md` and use it as your procedure."*
+
+### CLI Reference
+
+```bash
+kaizen-agentic protocols list                        # List all protocols
+kaizen-agentic protocols list sys-medic              # Filter by agent
+kaizen-agentic protocols show sys-medic k3s-node-health-assessment
+```
+
+### sys-medic Memory and Protocols Integration
+
+sys-medic extends the base memory template with three additional sections for operational continuity across sessions:
+
+```markdown
+## Node Profiles
+<!-- Per-node operational baseline established over sessions -->
+<!-- hostname | typical load | known quirks | last assessment date -->
+
+## Recurring Findings
+<!-- Issues seen more than once: pattern · first seen · frequency -->
+
+## Cleared Issues
+<!-- Issues that were resolved: what was done · when · outcome -->
+```
+
+These sections are maintained automatically by the sys-medic session-close protocol.
+
+The **k3s Node Health Assessment** (`agents/protocols/sys-medic/k3s-node-health-assessment.md`) is the first protocol runbook — a step-by-step procedure covering OS baseline, process hygiene, memory, CPU, disk, network, Kubernetes node state, and k3s runtime health.
+
+### Available Protocols
+
+| Agent | Protocol | Description |
+|-------|----------|-------------|
+| sys-medic | [k3s-node-health-assessment](../agents/protocols/sys-medic/k3s-node-health-assessment.md) | Structured k3s node health check |
+
+See [ADR-003: Protocols Artifact Convention](adr/ADR-003-protocols-artifact-convention.md) for the full specification.
+
+---
+
+## Agents with Memory Enabled
+
+All agents that do session-bound project work have `memory: enabled` in their frontmatter and include session-start/session-close protocol blocks:
+
+| Agent | Category | Notes |
+|-------|----------|-------|
+| project-management | process | Reference implementation of the session protocol pattern |
+| tdd-workflow | testing | |
+| requirements-engineering | process | |
+| scope-analyst | process | |
+| sys-medic | infrastructure | Extended memory template (node profiles, recurring findings) |
+| coach | meta | Fleet-level memory |
+
+---
+
+## Project Metrics
+
+Project-scoped **quantitative** metrics complement qualitative memory (ADR-002).
+Per-execution records live under `.kaizen/metrics/<agent>/` and feed the
+kaizen optimizer loop.
+
+### Location
+
+```
+<project-root>/.kaizen/metrics/<agent-name>/
+  executions.jsonl
+  summary.json
+
+<project-root>/.kaizen/metrics/optimizer/
+  analysis.json
+  recommendations.jsonl
+```
+
+### CLI (WP-0003)
+
+```
+kaizen-agentic metrics record <agent>   # Append execution record at session close
+kaizen-agentic metrics show <agent>     # Summary + recent executions
+kaizen-agentic metrics list             # Agents with metrics in project
+kaizen-agentic metrics export <agent>   # Dump executions.jsonl
+kaizen-agentic metrics optimize [agent] # Run optimizer on project metrics (≥10 records)
+kaizen-agentic metrics correlate <uid>  # Helix Forge digest lookup (read-only)
+kaizen-agentic metrics publish          # Register optimizer output in artifact-store
+```
+
+`memory brief` includes a `## Performance Summary` when metrics exist (success
+rate, avg quality, execution time, trend arrows).
+
+`memory init` scaffolds `.kaizen/metrics/<agent>/` by default (`--no-metrics` to
+skip). Record outcomes at session close per
+[session-close protocol template](templates/session-close-protocol.md).
+
+### Fleet correlation
+
+Project metrics correlate with **Helix Forge** fleet session metrics in
+`agentic-resources` via optional `helix_session_uid` (ADR-004).
+
+- `HELIX_SESSION_UID` (and related env vars) auto-merge on `metrics record`
+- `metrics correlate <uid>` looks up fleet digest when `HELIX_STORE_DB` is set
+
+See [integrations/helix-forge-correlation.md](integrations/helix-forge-correlation.md)
+and [wiki/EcosystemIntegration.md](../wiki/EcosystemIntegration.md).
+
+### Evidence retention
+
+After `metrics optimize`, optionally publish optimizer outputs to **artifact-store**:
+
+```bash
+export ARTIFACTSTORE_API_URL=http://127.0.0.1:8000
+export ARTIFACTSTORE_API_TOKEN=<write-token>
+kaizen-agentic metrics publish --target .
+```
+
+Package uses `retention_class: raw-evidence` (180d). Local
+`.kaizen/metrics/optimizer/` remains authoritative when publish is skipped.
+
+Manifest: [integrations/optimizer-artifact-manifest.md](integrations/optimizer-artifact-manifest.md).
+
+---
+
+## Scheduled Agent Execution
+
+Agents can run on a **regular cadence** against **preselected repos**, fired by
+**activity-core** and prepared by kaizen-agentic (ADR-005). A repo opts in by
+committing `.kaizen/schedule.yml`:
+
+```bash
+kaizen-agentic schedule init       # scaffold (coach + optimization weekly)
+kaizen-agentic schedule validate   # check schema + agent names
+kaizen-agentic schedule list       # show enabled entries
+kaizen-agentic schedule prepare coach   # orientation bundle for a scheduled run
+```
+
+`schedule prepare <agent>` bundles the agent prompt, project memory, metrics
+summary, and repo pointers — offline, no State Hub required. kaizen-agentic does
+**not** run cron or invoke Claude; activity-core fires the schedule and a
+coding-agent session executes the prepared bundle.
+
+Schema: [integrations/schedule-schema.md](integrations/schedule-schema.md).
+
+---
+
+## Related Documents
+
+- [ADR-001: Workplan Convention](adr/ADR-001-workplan-convention.md)
+- [ADR-002: Project Memory Convention](adr/ADR-002-project-memory-convention.md)
+- [ADR-003: Protocols Artifact Convention](adr/ADR-003-protocols-artifact-convention.md)
+- [ADR-004: Project Metrics Convention](adr/ADR-004-project-metrics-convention.md)
+- [ADR-005: Scheduled Agent Execution](adr/ADR-005-scheduled-agent-execution.md)
+- [wiki/EcosystemIntegration.md](../wiki/EcosystemIntegration.md) — two-layer measurement model
+- [WP-0002: Agency Framework](../workplans/kaizen-agentic-WP-0002-agency-framework.md)
+- [WP-0003: Measurement Loop](../workplans/kaizen-agentic-WP-0003-measurement-loop.md)
+- [WP-0004: Ecosystem Integration](../workplans/kaizen-agentic-WP-0004-ecosystem-integration.md)

docs/examples/.kaizen/schedule.yml

@@ -0,0 +1,17 @@
+# Kaizen scheduled agent execution manifest (ADR-005)
+# Declares which agents run on what cadence in this repo.
+# Validate with: kaizen-agentic schedule validate
+version: "1"
+timezone: Europe/Berlin
+agents:
+  coach:
+    cadence: weekly
+    cron: "0 9 * * 1" # Monday 09:00 — cross-agent orientation brief
+    enabled: true
+  optimization:
+    cadence: weekly
+    cron: "0 10 * * 1" # Monday 10:00 — agent performance review
+    enabled: true
+  tdd-workflow:
+    cadence: monthly
+    enabled: false # declared but paused; operator opts in deliberately

docs/integrations/activity-core-handoff-engagement.md

@@ -0,0 +1,109 @@
+# activity-core Handoff — Customer Engagement Bootstrap (WP-0008)
+
+Coordination requirements for **activity-core** to support coulomb-loop-style
+customer engagements after kaizen-agentic ships `schedule init --engagement` and
+`metrics record --emit-event`.
+
+Open as an activity-core issue titled *"Engagement bootstrap: event-payload +
+bootstrap cadence alignment"*.
+
+## Supplier capabilities (kaizen-agentic — done)
+
+- [x] `schedule init --engagement <slug> --agents coach,optimization --bootstrap-cadence hourly`
+- [x] `metrics record --emit-event` → `activity.kaizen.metrics.recorded`
+- [x] Resolver contract: [discover-kaizen-scheduled-repos.md](discover-kaizen-scheduled-repos.md)
+
+## activity-core requirements
+
+### R1 — `event-payload` context resolver (blocks LOOP-WP-0002 event path)
+
+**Problem:** Event-triggered definitions bind `context.metrics` via
+`type: event-payload`, but `resolve_context` treats unknown types as `{}`.
+
+**Requirement:** Register a resolver (or inline handler) that, when
+`event_envelope_json` is present, binds `EventEnvelope.attributes` to the
+`bind_to` key (stripping `context.` prefix).
+
+```yaml
+context_sources:
+  - type: event-payload
+    bind_to: context.metrics
+```
+
+Expected snapshot after resolve:
+
+```python
+{"metrics": {"agent": "coach", "project": "kaizen-agentic", "summary": {...}}}
+```
+
+**Acceptance:** Manual NATS publish of a [kaizen-metrics-recorded-event](kaizen-metrics-recorded-event.md)
+envelope triggers `low-success-rate-review` and evaluates
+`context.metrics.summary.success_rate` without binding `{}`.
+
+### R2 — Bootstrap cadence enum vs cron (blocks mis-tuned filters)
+
+**Problem:** Engagement bootstrap writes **hourly cron** expressions but keeps
+`cadence: daily` in `.kaizen/schedule.yml` (coulomb-loop ADR-003 convention).
+Customer ActivityDefinitions filter `discover_kaizen_scheduled_repos` with
+`cadence: daily`.
+
+**Requirement:** Do **not** require `cadence: hourly` in schedule.yml (invalid
+in ADR-005 schema). Continue matching on the `cadence` enum field; rely on
+per-repo `cron` overrides for hourly firing.
+
+**Acceptance:** Resolver with `cadence: daily` returns pilot repos whose
+`schedule.yml` contains `cron: "15 * * * *"` / `"30 * * * *"`.
+
+### R3 — ActivityDefinition cron alignment
+
+Customer coulomb definitions offset from repo schedule crons:
+
+| Definition | activity-core cron | Repo schedule cron |
+|------------|-------------------|-------------------|
+| hourly-metrics-optimize | `0 * * * *` | (metrics path; no schedule) |
+| hourly-coach-orientation | `15 * * * *` | coach `15 * * * *` |
+| hourly-optimization-review | `30 * * * *` | optimization `30 * * * *` |
+
+**Requirement:** Keep definition crons and repo schedule crons in sync during
+bootstrap. Document in customer handoff that `schedule init --engagement`
+presets must match enabled ActivityDefinition offsets.
+
+### R4 — Event router registration
+
+**Requirement:** Ensure `kaizen.metrics.recorded` is an allowed event type in
+`event_type_registry` (if registry is enforced on publish path).
+
+**Acceptance:** Event router dispatches to enabled `low-success-rate-review`
+definitions when envelope `type` matches.
+
+### R5 — Engagement roster path (optional v1.1)
+
+Customer rosters live in the engagement repo (e.g.
+`coulomb-loop/loops/kaizen-stack/roster.yaml`), not in target repos.
+
+**Suggestion:** Support optional resolver param `engagement_slug` that looks up
+roster path from a hub field or env `KAIZEN_ENGAGEMENT_ROSTER` so definitions
+need not hard-code absolute paths.
+
+## Smoke sequence (end-to-end)
+
+```bash
+# Target repo (supplier runs on pilot)
+kaizen-agentic schedule init --engagement coulomb-loop \
+  --agents coach,optimization --bootstrap-cadence hourly --force
+kaizen-agentic schedule validate
+kaizen-agentic memory init coach && kaizen-agentic memory init optimization
+
+# Record + emit (requires nats-py)
+kaizen-agentic metrics record coach --success --time 60 --quality 0.9 --emit-event
+
+# activity-core
+# 1. Resolver dry-run: discover_kaizen_scheduled_repos + cadence=daily → 6 runs
+# 2. Event dry-run: publish sample envelope → low-success-rate-review tasks
+```
+
+## Related
+
+- [customer engagement playbook](customer-engagement-playbook.md) (supplier)
+- coulomb-loop `docs/integrations/activity-core-handoff.md` (customer)
+- [KAIZEN-WP-0008](../../workplans/kaizen-agentic-WP-0008-coulomb-loop-supplier-engagement.md)

docs/integrations/activity-core-handoff-wp0006.md

@@ -0,0 +1,82 @@
+# activity-core Handoff — Scheduled Agent Execution (WP-0006)
+
+Coordination checklist for the **activity-core** team to enable kaizen scheduled
+agent runs. kaizen-agentic owns the schedule contract, the prepare CLI, and the
+ActivityDefinition **drafts**; activity-core owns the resolver, the schedule
+firing, and task creation (repo boundary, ADR-005).
+
+Open this as an activity-core issue/PR titled *"Enable kaizen scheduled agent
+execution (WP-0006)"* and track the boxes there.
+
+## What kaizen-agentic ships (done in this repo)
+
+- [x] `.kaizen/schedule.yml` schema + `schedule validate|init|list|prepare` CLI
+- [x] ADR-005 contract
+- [x] Resolver spec: [discover-kaizen-scheduled-repos.md](discover-kaizen-scheduled-repos.md)
+- [x] State Hub roster fields design: [state-hub-roster-fields.md](state-hub-roster-fields.md)
+- [x] Draft definitions (`enabled: false`):
+      [weekly-coach-orientation](activity-definitions/weekly-coach-orientation.md),
+      [weekly-optimization-review](activity-definitions/weekly-optimization-review.md)
+- [x] Event payload spec: [kaizen-schedule-prepared-event.md](kaizen-schedule-prepared-event.md)
+
+## What activity-core must do
+
+- [x] **Implement resolver** `discover_kaizen_scheduled_repos` per the spec
+      (`activity_core/context_resolvers/kaizen.py`).
+- [x] **Add resolver unit tests** — `tests/test_kaizen_context_resolver.py` (7 passed).
+- [ ] **Copy custodian weekly definitions** from `docs/integrations/activity-definitions/`
+      (`weekly-coach-orientation.md`, `weekly-optimization-review.md`) into the
+      activity-core catalog path (per ACT-ADR-002). *Deferred: coulomb-loop engagement
+      ships customer-owned daily bootstrap definitions instead (LOOP-WP-0001).*
+- [ ] **Register** weekly definition slugs in the activity-core index (when custodian
+      fleet moves off coulomb engagement copies).
+- [x] **Run** `make sync-activity-definitions` — coulomb-loop definitions synced
+      (`coulomb-hourly-coach-orientation`, `coulomb-hourly-optimization-review`, etc.).
+- [x] **Wire cron** triggers — daily stabilize chain on pilot roster (08:00–10:00).
+- [x] **Smoke test** — resolver dry-run returns 6 `scheduled_runs` on coulomb roster;
+      `schedule prepare coach` succeeds on `kaizen-agentic` and `the-custodian`.
+- [x] **Enable gradually** — coulomb bootstrap definitions `enabled: true` on pilot.
+- [x] **Verify runner prerequisites** — `kaizen-agentic` on PATH; `KAIZEN_RUNNER_HOST`
+      set on worker (`bnt-lap001`).
+
+### Supplier closure evidence (2026-06-18)
+
+| Check | Result |
+|-------|--------|
+| Resolver dry-run (coulomb roster, `cadence: daily`) | 6 runs across 3 pilot repos |
+| `tests/test_kaizen_context_resolver.py` | 7 passed |
+| `schedule validate` + `prepare coach` | OK on `kaizen-agentic`, `the-custodian`, `activity-core` |
+| Live definitions using resolver | `f234bb1a` coach, `097fc027` optimization (enabled) |
+
+**Remaining activity-core item:** optional custodian-fleet weekly templates (`enabled: false`
+in kaizen-agentic drafts) when engagement moves beyond coulomb-loop bootstrap copies.
+
+## State Hub team (the-custodian)
+
+- [ ] Optional: add `kaizen_schedule_enabled` repo flag + `GET /repos/` filter
+      (v2 pre-filter; the repo file remains the source of truth).
+
+## Smoke test (manual, runner-agnostic)
+
+```bash
+cd /path/to/pilot-repo
+kaizen-agentic schedule init            # if not already present
+kaizen-agentic schedule validate        # exit 0
+kaizen-agentic schedule list            # shows coach + optimization enabled
+kaizen-agentic schedule prepare coach   # non-empty orientation bundle
+```
+
+Then in activity-core: run the resolver (dry-run) and confirm one
+`scheduled_run` per enabled `(repo, agent)` with a correct `prepare_command`.
+
+## Pilot roster
+
+- `kaizen-agentic` (dogfood)
+- `the-custodian` (hub operator)
+- one additional custodian-domain repo with `.kaizen/` state (TBD at pilot time)
+
+## Related
+
+- [ADR-005](../adr/ADR-005-scheduled-agent-execution.md)
+- [INTEGRATION_PATTERNS.md Pattern 2](../INTEGRATION_PATTERNS.md)
+- [KAIZEN-WP-0006](../../workplans/kaizen-agentic-WP-0006-scheduled-agent-execution.md)

docs/integrations/activity-definition-override-manifest.md

@@ -0,0 +1,72 @@
+# ActivityDefinition Override Manifest (design)
+
+**Status:** design-only (DEC-003 option C future)
+**Implements:** KAIZEN-WP-0008 T08
+**Runtime:** none in v1 — customer-owned copies (option A) during bootstrap
+
+## Problem
+
+Customer repos copy supplier ActivityDefinitions and tune cron, labels, and
+`enabled` flags. When supplier templates change, manual merge is error-prone.
+A manifest declares **source + overrides** without duplicating full definition bodies.
+
+## Proposed file
+
+`activity-definitions/manifest.yaml` in the customer repo:
+
+```yaml
+version: "1"
+supplier_repo: kaizen-agentic
+supplier_path: docs/integrations/activity-definitions
+engagement: coulomb-loop
+
+definitions:
+  - supplier_id: kaizen-weekly-coach-orientation
+    customer_id: coulomb-hourly-coach-orientation
+    source: ../../kaizen-agentic/docs/integrations/activity-definitions/weekly-coach-orientation.md
+    overrides:
+      id: coulomb-hourly-coach-orientation
+      name: Hourly Kaizen Coach Orientation (coulomb-loop bootstrap)
+      owner: coulomb-loop
+      governance: coulomb_social
+      enabled: true
+      trigger:
+        cron_expression: "15 * * * *"
+      context_sources:
+        - params:
+            roster: /home/worsch/coulomb-loop/loops/kaizen-stack/roster.yaml
+            cadence: daily
+
+  - supplier_id: kaizen-low-success-rate-review
+    customer_id: coulomb-low-success-rate-review
+    overrides:
+      enabled: false
+      owner: coulomb-loop
+```
+
+## Merge rules (future tooling)
+
+1. Parse supplier definition markdown (frontmatter + body)
+2. Deep-merge `overrides` (customer wins on conflict)
+3. Write customer copy to `activity-definitions/<customer_id>.md`
+4. `sync_activity_definitions` reads customer copies only (unchanged today)
+
+## Ownership
+
+| Layer | Owner |
+|-------|-------|
+| Manifest schema | kaizen-agentic (supplier ADR/extension) |
+| Manifest instance | customer repo |
+| Merge CLI | TBD — `coulomb-loop` or `activity-core` |
+| Sync runtime | activity-core (unchanged) |
+
+## Bootstrap path (today)
+
+Use **option A**: hand-copy definitions, edit cron/labels, track drift in
+`loops/kaizen-stack/supplier-notes.md`. Revisit manifest when a second customer
+engagement starts.
+
+## Related
+
+- coulomb-loop `docs/decisions/DEC-003-activity-definition-ownership.md`
+- [customer-engagement-playbook.md](customer-engagement-playbook.md)

docs/integrations/activity-definitions/low-success-rate-review.md

@@ -0,0 +1,45 @@
+---
+id: kaizen-low-success-rate-review
+name: Low Agent Success Rate Review
+enabled: false
+owner: kaizen-agentic
+governance: custodian
+status: proposed
+trigger:
+  type: event
+  event_type: kaizen.metrics.recorded
+context_sources:
+  - type: event-payload
+    bind_to: context.metrics
+---
+
+# Low Agent Success Rate Review
+
+When a project agent's rolling success rate drops below 0.8, create a review
+task in issue-core for human or optimizer-agent follow-up.
+
+```rule
+id: flag-low-success-rate
+condition: 'context.metrics.summary.success_rate < 0.8 && context.metrics.summary.execution_count >= 5'
+action:
+  task_template: "Review {{context.metrics.agent}} success rate ({{context.metrics.summary.success_rate}})"
+  description: |
+    Agent {{context.metrics.agent}} in {{context.metrics.project}} has success_rate
+    below 0.8 over {{context.metrics.summary.execution_count}} executions.
+    Run: kaizen-agentic metrics show {{context.metrics.agent}}
+    Then: kaizen-agentic metrics optimize {{context.metrics.agent}}
+  target_repo: "{{context.metrics.project}}"
+  priority: high
+  labels: ["kaizen", "metrics", "review", "automated"]
+```
+
+**Threshold:** 0.8 success rate, minimum 5 executions (avoids noise on early pilots).
+
+**CLI mapping:** `kaizen-agentic metrics record <agent> --emit-event` after each
+append (see [kaizen-metrics-recorded-event.md](../kaizen-metrics-recorded-event.md)).
+Manual check today:
+
+```bash
+kaizen-agentic metrics show <agent>   # inspect summary.success_rate
+kaizen-agentic metrics optimize <agent>
+```

docs/integrations/activity-definitions/post-install-metrics-scaffold.md

@@ -0,0 +1,41 @@
+---
+id: kaizen-post-install-metrics-scaffold
+name: Post-Install Metrics Scaffold Validation
+enabled: false
+owner: kaizen-agentic
+governance: custodian
+status: proposed
+trigger:
+  type: event
+  event_type: kaizen.agent.installed
+context_sources:
+  - type: event-payload
+    bind_to: context.install
+---
+
+# Post-Install Metrics Scaffold Validation
+
+Fires when an agent is installed into a project. Verifies that memory and metrics
+scaffolds exist for the installed agent.
+
+```rule
+id: validate-metrics-scaffold
+condition: 'context.install.agent != ""'
+action:
+  task_template: "Validate kaizen scaffold for {{context.install.agent}}"
+  description: |
+    In {{context.install.project_root}} verify:
+    - .kaizen/agents/{{context.install.agent}}/memory.md exists OR run:
+      kaizen-agentic memory init {{context.install.agent}}
+    - .kaizen/metrics/{{context.install.agent}}/ exists OR re-run init without --no-metrics
+  target_repo: "{{context.install.repo}}"
+  priority: low
+  labels: ["kaizen", "metrics", "scaffold", "automated"]
+```
+
+**CLI mapping:**
+
+```bash
+kaizen-agentic memory init <agent>    # scaffolds memory + metrics by default
+kaizen-agentic metrics list           # confirms metrics directory after first record
+```

docs/integrations/activity-definitions/weekly-coach-orientation.md

@@ -0,0 +1,55 @@
+---
+id: kaizen-weekly-coach-orientation
+name: Weekly Kaizen Coach Orientation
+enabled: false
+owner: kaizen-agentic
+governance: custodian
+status: proposed
+trigger:
+  type: cron
+  cron_expression: "0 9 * * 1"
+  timezone: Europe/Berlin
+  misfire_policy: skip
+context_sources:
+  - type: resolver
+    query: discover_kaizen_scheduled_repos
+    params:
+      domain: custodian
+      cadence: weekly
+    bind_to: context.scheduled_runs
+---
+
+# Weekly Kaizen Coach Orientation
+
+Every Monday 09:00 Berlin time, opens a coach orientation task for each
+schedule-eligible repo whose `.kaizen/schedule.yml` enables the `coach` agent.
+
+The resolver `discover_kaizen_scheduled_repos` (see
+[discover-kaizen-scheduled-repos.md](../discover-kaizen-scheduled-repos.md))
+returns one `scheduled_run` per `(repo, agent)`; this definition selects the
+`coach` runs.
+
+```rule
+id: run-weekly-coach
+for_each: context.scheduled_runs
+bind_as: r
+condition: 'context.r.agent == "coach" and context.r.enabled'
+action:
+  task_template: "Weekly coach orientation: {context.r.repo}"
+  description: |
+    {context.r.prepare_command}
+    Then load agents/agent-coach.md in a coding-agent session, paste the
+    prepared bundle, and follow the coach synthesis. At session close:
+    kaizen-agentic metrics record coach --success --time <s> --quality <0-1>
+  target_repo: context.r.repo
+  priority: medium
+  labels: ["kaizen", "agent-run", "coach", "scheduled", "automated"]
+```
+
+**CLI mapping:** `kaizen-agentic schedule prepare coach` (offline-safe; reads
+local `.kaizen/` state).
+
+**Activation:** sync into activity-core via `make sync-activity-definitions`
+after the `discover_kaizen_scheduled_repos` resolver is enabled. Keep
+`enabled: false` until a manual smoke test passes on a pilot repo. See
+[INTEGRATION_PATTERNS.md Pattern 2](../../INTEGRATION_PATTERNS.md).

docs/integrations/activity-definitions/weekly-metrics-optimize.md

@@ -0,0 +1,44 @@
+---
+id: kaizen-weekly-metrics-optimize
+name: Weekly Kaizen Metrics Optimization
+enabled: false
+owner: kaizen-agentic
+governance: custodian
+status: proposed
+trigger:
+  type: cron
+  cron_expression: "0 8 * * 1"
+  timezone: Europe/Berlin
+  misfire_policy: skip
+context_sources:
+  - type: shell
+    query: discover_kaizen_projects
+    params:
+      marker: .kaizen/metrics
+    bind_to: context.projects
+---
+
+# Weekly Kaizen Metrics Optimization
+
+Runs every Monday 08:00 Berlin time on repos that contain `.kaizen/metrics/`.
+Invokes the kaizen-agentic optimizer CLI per project.
+
+```rule
+id: run-weekly-optimizer
+for_each: context.projects
+bind_as: p
+condition: 'context.p.has_metrics'
+action:
+  task_template: "Run kaizen metrics optimize on {context.p.repo}"
+  description: |
+    cd {context.p.root} && kaizen-agentic metrics optimize
+    Optional: kaizen-agentic metrics publish (when artifact-store configured)
+  target_repo: context.p.repo
+  priority: medium
+  labels: ["kaizen", "metrics", "optimizer", "automated"]
+```
+
+**Activation:** sync this definition into activity-core via `make sync-activity-definitions`
+after enabling the shell resolver for `discover_kaizen_projects`.
+
+**CLI mapping:** `kaizen-agentic metrics optimize` (no agent filter = all agents with metrics).

docs/integrations/activity-definitions/weekly-optimization-review.md

@@ -0,0 +1,55 @@
+---
+id: kaizen-weekly-optimization-review
+name: Weekly Kaizen Optimization Review
+enabled: false
+owner: kaizen-agentic
+governance: custodian
+status: proposed
+trigger:
+  type: cron
+  cron_expression: "0 10 * * 1"
+  timezone: Europe/Berlin
+  misfire_policy: skip
+context_sources:
+  - type: resolver
+    query: discover_kaizen_scheduled_repos
+    params:
+      domain: custodian
+      cadence: weekly
+    bind_to: context.scheduled_runs
+---
+
+# Weekly Kaizen Optimization Review
+
+Every Monday 10:00 Berlin time, opens an optimization-agent review task for each
+schedule-eligible repo whose `.kaizen/schedule.yml` enables the `optimization`
+agent. Chains the agent orientation with the existing metrics optimizer so the
+review is evidence-backed.
+
+```rule
+id: run-weekly-optimization
+for_each: context.scheduled_runs
+bind_as: r
+condition: 'context.r.agent == "optimization" and context.r.enabled'
+action:
+  task_template: "Weekly optimization review: {context.r.repo}"
+  description: |
+    {context.r.prepare_command}
+    kaizen-agentic metrics optimize          # refresh evidence
+    Then load agents/agent-optimization.md, paste the prepared bundle plus the
+    optimizer report, and act on recommendations. At session close:
+    kaizen-agentic metrics record optimization --success --time <s> --quality <0-1>
+  target_repo: context.r.repo
+  priority: medium
+  labels: ["kaizen", "agent-run", "optimization", "scheduled", "automated"]
+```
+
+**CLI mapping:** `kaizen-agentic schedule prepare optimization` then
+`kaizen-agentic metrics optimize`.
+
+**Complementarity:** this generalizes the metrics-only
+[weekly-metrics-optimize](weekly-metrics-optimize.md) definition into a full
+agent run. Repos may run either; running both duplicates the optimizer step.
+
+**Activation:** sync into activity-core via `make sync-activity-definitions`
+after the resolver is enabled; hold at `enabled: false` until smoke-tested.

docs/integrations/briefs/tdd-workflow-canon-brief.md

@@ -0,0 +1,44 @@
+# tdd-workflow — InfoTechCanon-style Brief
+
+Compact agent brief derived from `agents/agent-tdd-workflow.md` (metrics pilot).
+Reference for fleet-wide brief rollout.
+
+```yaml
+profile:
+  id: kaizen/tdd-workflow
+  version: "1.0"
+  domain: development-process
+  intent:
+    summary: Guide TDD8 ISSUE-TEST-RED-GREEN-REFACTOR-DOCUMENT-REFINE-PUBLISH cycles
+    outcomes:
+      - Acceptance criteria covered by tests before PUBLISH
+      - Sidequests tracked without blocking parent issues
+      - Workspace integrated cleanly via make tdd-finish
+  metrics:
+    primary:
+      name: test_pass_rate
+      target: 1.0
+      measurement: passing_tests / total_tests at PUBLISH
+    secondary:
+      - name: cycle_time_s
+        measurement: session duration (execution_time_s)
+    collection:
+      storage: .kaizen/metrics/tdd-workflow/
+      frequency: per_execution
+  idempotency:
+    signals:
+      - current_issue.json workspace state
+      - idempotency_key on metrics record
+  session_protocol:
+    start: read .kaizen/agents/tdd-workflow/memory.md
+    close:
+      - update memory.md sections
+      - kaizen-agentic metrics record tdd-workflow
+  ecosystem:
+    fleet_correlation: helix_session_uid (ADR-004)
+    optimizer: kaizen-agentic metrics optimize
+    evidence: kaizen-agentic metrics publish (optional)
+```
+
+Full specification: [agents/agent-tdd-workflow.md](../../../agents/agent-tdd-workflow.md).
+Pilot documentation: [wiki/AboutKaizenAgents.md](../../../wiki/AboutKaizenAgents.md).

docs/integrations/canon-template-mapping.md

@@ -0,0 +1,32 @@
+# KaizenAgentTemplate → InfoTechCanon Profile Mapping
+
+Design note (WP-0004 Part 4). No runtime dependency on info-tech-canon.
+
+## Section mapping
+
+| `wiki/KaizenAgentTemplate.md` | InfoTechCanon profile outline |
+|------------------------------|------------------------------|
+| `specification.outcomes` | `profile.intent.outcomes[]` |
+| `specification.constraints` | `profile.constraints.hard[]` / `soft[]` |
+| `idempotency.detection` | `profile.idempotency.signals[]` |
+| `idempotency.rollback` | `profile.safety.rollback` |
+| `metrics.primary` | `profile.metrics.primary` |
+| `metrics.secondary[]` | `profile.metrics.secondary[]` |
+| `metrics.collection` | `profile.observability.collection` |
+| `testing.unit_tests[]` | `profile.validation.unit[]` |
+| `testing.integration_tests[]` | `profile.validation.integration[]` |
+| `evolution.history` | `profile.evolution.changelog` |
+| `evolution.optimization_hooks` | `profile.evolution.feedback_sources[]` |
+
+## Validation hooks (future)
+
+Extend `kaizen-agentic validate` to check:
+
+1. Frontmatter contains `metrics.primary.name` when `memory: enabled`
+2. Session-close block references `metrics record`
+3. Required template sections present in agent body (warn, not fail)
+
+## Reference pilot
+
+`tdd-workflow` brief in [briefs/tdd-workflow-canon-brief.md](briefs/tdd-workflow-canon-brief.md)
+demonstrates a compact canon-style export derived from the full agent spec.

docs/integrations/customer-engagement-playbook.md

@@ -0,0 +1,98 @@
+# Customer Engagement Playbook v1 (supplier)
+
+How kaizen-agentic supports a **customer engagement repo** (reference:
+[coulomb-loop](https://gitea.coulomb.social/coulomb/coulomb-loop)). Second engagements
+should copy [customer-engagement-repo-layout.md](customer-engagement-repo-layout.md)
+and complete the checklist in one session.
+
+## Roles
+
+| Repo | Role |
+|------|------|
+| Customer (coulomb-loop) | Roster, ActivityDefinition copies, cadence policy, loop health |
+| Supplier (kaizen-agentic) | Agents, CLI, integration contracts, this playbook |
+| Target repos | `.kaizen/` state (schedule, memory, metrics) |
+| activity-core | Cron + event orchestration, task creation |
+
+## Bootstrap checklist
+
+### 1. Customer repo
+
+- Register engagement in state-hub (`register_project.sh`)
+- Write `INTENT.md`, `SCOPE.md`, LOOP-WP-0000–0004 workplans
+- Accept ADRs and DEC-* decisions; run `fix-consistency REPO=<customer>`
+- Copy ActivityDefinitions to `activity-definitions/` (DEC-003 option A)
+- Register reuse-surface capability (LOOP-WP-0000 T08)
+- Enable definitions incrementally: metrics → coach → optimization
+
+### 2. Target repos (per pilot)
+
+```bash
+kaizen-agentic schedule init --engagement <customer-slug> \
+  --agents coach,optimization --bootstrap-cadence hourly
+kaizen-agentic schedule validate
+kaizen-agentic memory init coach
+kaizen-agentic memory init optimization
+```
+
+Hourly bootstrap uses `cadence: daily` with hourly `cron` overrides — see
+[activity-core-handoff-engagement.md](activity-core-handoff-engagement.md) R2.
+
+### 3. Session close (each agent run)
+
+```bash
+kaizen-agentic metrics record <agent> --success --time <s> --quality <0-1>
+kaizen-agentic metrics record <agent> --success --time <s> --quality <0-1> --emit-event
+```
+
+Requires `pip install 'kaizen-agentic[events]'` for `--emit-event`.
+
+### 4. activity-core
+
+- Sync definitions from customer `activity-definitions/`
+- Implement handoff requirements in [activity-core-handoff-engagement.md](activity-core-handoff-engagement.md)
+- Manual trigger smoke before enabling hourly crons
+
+## Lessons from coulomb-loop (supplier-notes absorbed)
+
+| Observation | Resolution (shipped) |
+|-------------|----------------------|
+| `schedule init` weekly defaults unsuitable for bootstrap | `schedule init --engagement --bootstrap-cadence hourly` (KAIZEN-WP-0008 T04) |
+| No metrics event for LOOP-WP-0002 | `metrics record --emit-event` (T03) |
+| `metrics optimize` with 0 records confusing during bootstrap | Expected — document in bootstrap log; optimizer needs ≥10 records for recommendations |
+| ActivityDefinition drift from supplier templates | Customer copies (DEC-003 A); hybrid manifest design for v2 ([override manifest](activity-definition-override-manifest.md)) |
+| Rotation saturation signals | Future: `metrics rotation-signals` CLI (ADR-004 follow-on) |
+
+## Cadence promotion
+
+Customer regulator (LOOP-WP-0004) approves promotion. Use atomic promote to
+align all three layers (cadence.yml, activity-definitions, fleet schedule.yml,
+activity-core sync):
+
+```bash
+kaizen-agentic schedule promote \
+  --engagement-repo /path/to/customer-loop \
+  --engagement <slug> \
+  --to-phase operate \
+  --activity-core /path/to/activity-core
+```
+
+Dry-run: `--dry-run`. Repair fleet drift after a partial promotion: `--fleet-only`.
+
+Legacy per-layer commands still work:
+
+```bash
+kaizen-agentic schedule init --engagement <slug> --bootstrap-cadence daily --force
+kaizen-agentic schedule init --engagement <slug> --bootstrap-cadence weekly --force
+```
+
+## Reference implementation
+
+- Customer: [coulomb-loop INTENT](https://gitea.coulomb.social/coulomb/coulomb-loop/src/branch/main/INTENT.md)
+- Supplier workplan: [KAIZEN-WP-0008](../../workplans/kaizen-agentic-WP-0008-coulomb-loop-supplier-engagement.md)
+- Convention: [ADR-006](../adr/ADR-006-customer-engagement-convention.md)
+
+## Related
+
+- [INTEGRATION_PATTERNS.md](../INTEGRATION_PATTERNS.md) Pattern 2
+- [activity-core-handoff-wp0006.md](activity-core-handoff-wp0006.md)

docs/integrations/customer-engagement-repo-layout.md

@@ -0,0 +1,65 @@
+# Customer Engagement Repo Layout
+
+Contract for a **customer engagement repository** that orchestrates kaizen
+improvement loops across a fleet roster. Reference implementation:
+[coulomb-loop](https://gitea.coulomb.social/coulomb/coulomb-loop) (`coulomb_social` domain).
+
+Supplier agents and CLI live in `kaizen-agentic`. Runtime `.kaizen/` state lives
+in **target repos**, not in the customer repo.
+
+## Directory tree
+
+```
+customer-repo/
+├── INTENT.md                 # Engagement purpose, loop map, cadence policy summary
+├── SCOPE.md                  # In/out of scope; supplier boundaries
+├── CLAUDE.md                 # Session protocol + rules includes
+├── .claude/rules/            # repo-identity, architecture, workplan-convention, …
+├── workplans/
+│   ├── <PREFIX>-WP-0000-*    # Bootstrap (registration, ADRs, decisions)
+│   ├── <PREFIX>-WP-0001-*    # Primary improvement stack
+│   ├── <PREFIX>-WP-0002-*    # Reactive quality escalation
+│   ├── <PREFIX>-WP-0003-*    # Registry / orientation hygiene
+│   └── <PREFIX>-WP-0004-*    # Loop regulator (cadence promotion, rotation)
+├── docs/
+│   ├── adr/                  # Customer ADRs (boundary, cadence, ownership)
+│   ├── decisions/            # DEC-* proposals awaiting operator acceptance
+│   └── integrations/         # activity-core handoff, event payloads
+├── history/                  # Assessments, milestone snapshots
+├── activity-definitions/     # Customer-owned copies (DEC-003 option A)
+├── loops/
+│   └── <loop-id>/
+│       ├── roster.yaml       # Pilot + expansion_queue + saturated
+│       ├── bootstrap-log.md  # E2E cycle evidence
+│       ├── supplier-notes.md # Friction fed back to kaizen-agentic
+│       └── rotation-policy.yml  # ADR-004 diminishing-returns (optional)
+└── registry/                 # reuse-surface capability index (engagement D0)
+    ├── indexes/capabilities.yaml
+    └── capabilities/
+```
+
+## Naming
+
+| Artifact | coulomb-loop example |
+|----------|----------------------|
+| Workplan prefix | `LOOP-WP-NNNN` |
+| Hub topic slug | `coulomb_social` |
+| Engagement slug in schedules | `coulomb-loop` |
+| Supplier workplan | `KAIZEN-WP-0008` (kaizen-agentic) |
+
+## What does not live here
+
+- `agents/agent-*.md` — supplier (`kaizen-agentic`)
+- `.kaizen/schedule.yml` on customer repo — target fleet repos only
+- Temporal workers / resolvers — `activity-core`
+- state-hub service code — `the-custodian`
+
+## Bootstrap sequence
+
+See [customer-engagement-playbook.md](customer-engagement-playbook.md).
+
+## Related
+
+- coulomb-loop `docs/adr/ADR-002-customer-supplier-boundary.md`
+- [ADR-006](../adr/ADR-006-customer-engagement-convention.md)
+- [KAIZEN-WP-0008](../../workplans/kaizen-agentic-WP-0008-coulomb-loop-supplier-engagement.md)

docs/integrations/discover-kaizen-scheduled-repos.md

@@ -0,0 +1,109 @@
+# Resolver Spec: `discover_kaizen_scheduled_repos`
+
+**Status:** implemented in activity-core (`context_resolvers/kaizen.py`). This doc
+is the contract an activity-core implementer needs to add the context resolver
+that feeds the scheduled-agent ActivityDefinitions (ADR-005).
+
+## Purpose
+
+Given the fleet roster and per-repo schedule manifests, emit one entry per
+`(repo, agent)` that is due to run, so ActivityDefinitions can `for_each` over
+the result.
+
+## Signature
+
+```
+discover_kaizen_scheduled_repos(
+    domain: str | None = None,        # optional scope filter, e.g. "custodian"
+    cadence: str | None = None,       # optional: "daily" | "weekly" | "monthly"
+    now: datetime | None = None,      # injection point for testing
+) -> { "scheduled_runs": list[ScheduledRun] }
+```
+
+Bound in a definition as:
+
+```yaml
+context_sources:
+  - type: resolver
+    query: discover_kaizen_scheduled_repos
+    params:
+      domain: custodian
+      cadence: weekly
+    bind_to: context.scheduled_runs
+```
+
+## Inputs (sources, in order)
+
+1. **State Hub** `GET /repos/` (optionally filtered by `domain` and, when the v2
+   flag lands, `kaizen_schedule_enabled=true`). Yields `slug`, `host_paths`,
+   `domain`.
+2. **Repo checkout** at `host_paths[<runner-host>]`: read
+   `.kaizen/schedule.yml`. Skip repos without the file.
+3. **Validation**: run the equivalent of `kaizen-agentic schedule validate`.
+   Skip (and log) repos whose schedule is invalid — never emit a bad entry.
+
+## Output shape
+
+```json
+{
+  "scheduled_runs": [
+    {
+      "repo": "kaizen-agentic",
+      "root": "/home/worsch/kaizen-agentic",
+      "agent": "coach",
+      "cadence": "weekly",
+      "cron": "0 9 * * 1",
+      "timezone": "Europe/Berlin",
+      "enabled": true,
+      "prepare_command": "kaizen-agentic schedule prepare coach --target /home/worsch/kaizen-agentic"
+    }
+  ]
+}
+```
+
+### `ScheduledRun` fields
+
+| Field | Source | Notes |
+|-------|--------|-------|
+| `repo` | hub `slug` | becomes `target_repo` on the created task |
+| `root` | `host_paths[<host>]` | absolute checkout path on the runner |
+| `agent` | schedule.yml key | |
+| `cadence` | schedule.yml | |
+| `cron` | schedule.yml or definition default | per-repo override when present |
+| `timezone` | schedule.yml or definition default | |
+| `enabled` | schedule.yml (`true` only emitted) | disabled entries are filtered out |
+| `prepare_command` | derived | exact CLI the task should run |
+
+## Filtering rules
+
+- Emit only entries with `enabled: true`.
+- When `cadence` param is set, emit only matching entries (lets each cron-bound
+  definition select its own cadence slice).
+- When `cron` is present on the entry, it is the authoritative per-repo time;
+  otherwise the definition's cron applies.
+
+## Errors
+
+| Condition | Behavior |
+|-----------|----------|
+| Repo unreachable / path missing on host | Skip + log `repo_unreachable` |
+| `.kaizen/schedule.yml` absent | Skip silently (not opted in) |
+| schedule.yml invalid | Skip + log `schedule_invalid` with validation errors |
+| Hub unreachable | Fail the resolver run (no roster = no safe output) |
+
+The resolver must be **idempotent** and **side-effect free**: it reads, it does
+not write. Task creation happens in the ActivityDefinition rule, not here.
+
+## Test fixtures
+
+- A repo with valid `.kaizen/schedule.yml` (coach enabled) → one entry.
+- A repo with the file but coach `enabled: false` → no entry.
+- A repo without the file → no entry.
+- A repo with an invalid schedule → no entry + logged error.
+
+## Related
+
+- [state-hub-roster-fields.md](state-hub-roster-fields.md)
+- [schedule-schema.md](schedule-schema.md)
+- [activity-definitions/weekly-coach-orientation.md](activity-definitions/weekly-coach-orientation.md)
+- [ADR-005](../adr/ADR-005-scheduled-agent-execution.md)

docs/integrations/helix-forge-correlation.md

@@ -0,0 +1,103 @@
+# Helix Forge Correlation Contract
+
+Cross-repo contract between **kaizen-agentic** (project metrics, ADR-004) and
+**agentic-resources** (Helix Forge fleet session metrics).
+
+## Purpose
+
+Link a project-scoped agent execution record to the fleet session that produced
+it, without duplicating session JSONL ingestion in kaizen-agentic.
+
+## Layers
+
+| Layer | Owner | Storage |
+|-------|-------|---------|
+| Project | kaizen-agentic | `.kaizen/metrics/<agent>/executions.jsonl` |
+| Fleet | agentic-resources | Helix Forge digest store (`digests` table) |
+
+## Correlation fields (ADR-004)
+
+Optional on each project execution record:
+
+```json
+{
+  "helix_session_uid": "claude:17092961-…",
+  "repo": "kaizen-agentic",
+  "flavor": "claude",
+  "tokens": 12500,
+  "infra_overhead_share": 0.12
+}
+```
+
+### Field mapping
+
+| Helix Forge (`session_memory`) | ADR-004 project record |
+|-------------------------------|------------------------|
+| `Session.session_uid` | `helix_session_uid` |
+| `Session.repo` | `repo` |
+| `Session.flavor` | `flavor` |
+| `digest.cost.input_tokens + output_tokens` | `tokens` |
+| MCP tool share of `tool_histogram` | `infra_overhead_share` |
+| `digest.outcome == "success"` | informs `success` at record time |
+| `digest.cost.wall_clock_s` | complements `execution_time_s` |
+
+## Population at session close
+
+### Automatic (environment)
+
+When Helix Forge capture is active in the same shell session:
+
+```bash
+export HELIX_SESSION_UID="claude:17092961-…"
+export HELIX_REPO="kaizen-agentic"
+export HELIX_FLAVOR="claude"
+export HELIX_TOKENS="12500"
+export HELIX_INFRA_OVERHEAD_SHARE="0.12"
+
+kaizen-agentic metrics record tdd-workflow --success --time 4200 --quality 0.9
+```
+
+`metrics record` merges env vars into the execution record before append.
+
+### Explicit (JSON)
+
+```bash
+echo '{
+  "success": true,
+  "execution_time_s": 4200,
+  "quality_score": 0.9,
+  "helix_session_uid": "claude:17092961-…",
+  "repo": "kaizen-agentic",
+  "flavor": "claude",
+  "tokens": 12500,
+  "infra_overhead_share": 0.12
+}' | kaizen-agentic metrics record tdd-workflow --json
+```
+
+## Fleet lookup (read-only)
+
+```bash
+export HELIX_STORE_DB=~/.helix-forge/store.db   # agentic-resources session store
+kaizen-agentic metrics correlate claude:17092961-…
+```
+
+When `HELIX_STORE_DB` is unset, `metrics correlate` returns a **stub** response
+documenting expected fields — no ingestion code runs in kaizen-agentic.
+
+## Bidirectional references
+
+| Document | Repo |
+|----------|------|
+| [ADR-004](../adr/ADR-004-project-metrics-convention.md) | kaizen-agentic |
+| [wiki/EcosystemIntegration.md](../../wiki/EcosystemIntegration.md) | kaizen-agentic |
+| [DESIGN-session-memory.md](https://github.com/coulomb/agentic-resources/blob/main/docs/DESIGN-session-memory.md) | agentic-resources |
+| `session_memory/core/store.py` — `get_digest()` | agentic-resources |
+
+**Reciprocal link status:** verified (WP-0005 T16). `agentic-resources/docs/DESIGN-session-memory.md`
+§11 cites this document and ADR-004.
+
+## Non-goals
+
+- No Claude/Codex/Grok JSONL ingestion in kaizen-agentic
+- No write path to Helix Forge from kaizen-agentic CLI
+- No merge of fleet baselines into project `summary.json` (Coach may cite both)

docs/integrations/kaizen-metrics-recorded-event.md

@@ -0,0 +1,73 @@
+# Event Payload: `kaizen.metrics.recorded`
+
+**Status:** implemented — `kaizen-agentic metrics record --emit-event`
+
+**Registry:** `event-types/kaizen.metrics.recorded.md` (producer-owned, synced via
+activity-core `make sync-event-types` with `ACTIVITY_DEFINITION_DIRS` including
+this repo)
+
+Emitted after a successful metrics append when `--emit-event` is set. Default
+off for backward compatibility.
+
+## Subject
+
+```
+activity.kaizen.metrics.recorded
+```
+
+Published to NATS (activity-core `EventEnvelope` format). Consumed by
+activity-core event router and definitions such as `low-success-rate-review`.
+
+## Envelope
+
+```json
+{
+  "id": "550e8400-e29b-41d4-a716-446655440000",
+  "type": "kaizen.metrics.recorded",
+  "version": "1.0",
+  "timestamp": "2026-06-18T12:00:00Z",
+  "publisher": "kaizen-agentic",
+  "attributes": {
+    "agent": "coach",
+    "project": "kaizen-agentic",
+    "summary": {
+      "success_rate": 0.75,
+      "execution_count": 12,
+      "avg_quality": 0.81
+    }
+  }
+}
+```
+
+### Attribute fields
+
+| Field | Type | Notes |
+|-------|------|-------|
+| `agent` | string | Agent name from `metrics record <agent>` |
+| `project` | string | Repo slug — `KAIZEN_PROJECT_SLUG` env or directory basename |
+| `summary.success_rate` | float | Rolling rate from `summary.json` after append |
+| `summary.execution_count` | int | Total executions |
+| `summary.avg_quality` | float | Maps from `avg_quality_score` in ADR-004 summary |
+
+## CLI
+
+```bash
+kaizen-agentic metrics record coach --success --time 120 --quality 0.9 --emit-event
+```
+
+Requires `nats-py` (`pip install 'kaizen-agentic[events]'`). Configure broker via
+`NATS_URL` (default `nats://localhost:4222`).
+
+Events are **not** emitted when append is skipped (duplicate idempotency key).
+
+## Consumers
+
+- **activity-core** — `trigger.type: event` with `event_type: kaizen.metrics.recorded`
+- **coulomb-loop** — `low-success-rate-review` (LOOP-WP-0002); replaces hourly
+  health sweep when event path is stable
+
+## Related
+
+- [low-success-rate-review](activity-definitions/low-success-rate-review.md)
+- [INTEGRATION_PATTERNS.md Pattern 2](../INTEGRATION_PATTERNS.md)
+- coulomb-loop `loops/quality-escalation/event-payload.md` (customer contract)

docs/integrations/kaizen-schedule-prepared-event.md

@@ -0,0 +1,90 @@
+# Event Payload: `kaizen.schedule.prepared`
+
+**Status:** design — for **future event-driven runs**. v1 of WP-0006 is
+cron-driven (activity-core fires the schedule). This event lets a runner or
+activity-core react when a `schedule prepare` bundle has been assembled, without
+polling.
+
+kaizen-agentic does **not** publish this event today; the `prepare` command
+writes to stdout. This spec fixes the contract so an emitter (a runner wrapper
+or a thin `--emit` flag in a later iteration) and consumers agree on the shape.
+
+## Subject
+
+```
+kaizen.schedule.prepared
+```
+
+NATS/event-bus subject, sibling to the existing `kaizen.metrics.recorded` and
+`kaizen.agent.installed` subjects (Pattern 2).
+
+## Payload
+
+```json
+{
+  "event": "kaizen.schedule.prepared",
+  "version": "1",
+  "occurred_at": "2026-06-17T09:00:12Z",
+  "repo": "kaizen-agentic",
+  "root": "/home/worsch/kaizen-agentic",
+  "agent": "coach",
+  "cadence": "weekly",
+  "prepare_command": "kaizen-agentic schedule prepare coach --target /home/worsch/kaizen-agentic",
+  "bundle": {
+    "format": "markdown",
+    "agent_prompt_found": true,
+    "has_memory": true,
+    "has_metrics": true,
+    "pointers": ["scope", "workplans"],
+    "bytes": 8421
+  },
+  "session_close": [
+    "kaizen-agentic metrics record coach --success --time <s> --quality <0-1>"
+  ]
+}
+```
+
+### Fields
+
+| Field | Type | Notes |
+|-------|------|-------|
+| `event` | string | Always `kaizen.schedule.prepared` |
+| `version` | string | Payload schema version |
+| `occurred_at` | RFC3339 | When the bundle was assembled |
+| `repo` | string | State Hub slug |
+| `root` | string | Absolute checkout path |
+| `agent` | string | Agent the bundle orients |
+| `cadence` | string | `daily` \| `weekly` \| `monthly` |
+| `prepare_command` | string | Exact CLI that produced the bundle |
+| `bundle.format` | string | `markdown` \| `json` |
+| `bundle.agent_prompt_found` | bool | Mirrors `schedule prepare --format json` |
+| `bundle.has_memory` | bool | Memory file present |
+| `bundle.has_metrics` | bool | Metrics summary present |
+| `bundle.pointers` | string[] | Repo pointer labels found (`scope`, `workplans`) |
+| `bundle.bytes` | int | Rendered bundle size |
+| `session_close` | string[] | Suggested close commands |
+
+The `bundle.*` flags map 1:1 to the JSON output of
+`kaizen-agentic schedule prepare <agent> --format json`, so an emitter can build
+this payload from the existing command without new computation.
+
+## Consumers (illustrative)
+
+- **activity-core** — close the loop: mark the scheduled task `in_progress` when
+  a bundle is prepared.
+- **artifact-store** — archive large bundles by reference.
+- **dashboards** — fleet view of which scheduled runs have been prepared vs.
+  executed.
+
+## Boundary
+
+- The payload carries **metadata and a command**, never secrets or full repo
+  contents.
+- kaizen-agentic owns the schema; emission wiring (NATS publish) is a future
+  iteration and belongs to the runner / activity-core integration.
+
+## Related
+
+- [discover-kaizen-scheduled-repos.md](discover-kaizen-scheduled-repos.md)
+- [INTEGRATION_PATTERNS.md Pattern 2](../INTEGRATION_PATTERNS.md)
+- [ADR-005](../adr/ADR-005-scheduled-agent-execution.md)

docs/integrations/kontextual-wiki-ingestion-spike.md

@@ -0,0 +1,41 @@
+# kontextual-engine Wiki Ingestion Spike
+
+Design note (WP-0004 Part 4). No runtime dependency.
+
+## Proposed manifest
+
+```yaml
+ingestion:
+  source_repo: kaizen-agentic
+  asset_class: strategic-knowledge
+  paths:
+    - wiki/**/*.md
+    - INTENT.md
+    - docs/adr/ADR-*.md
+  exclude:
+    - wiki/**/xxx
+  metadata:
+    domain: custodian
+    topic_id: cee7bedf-2b48-46ef-8601-006474f2ad7a
+    producer: kaizen-agentic
+  refresh:
+    trigger: git-push-main
+    retention_class: operational-knowledge
+```
+
+## Rationale
+
+- `wiki/` holds product narrative and integration contracts not suited for agent prompts alone
+- ADRs are normative; kontextual-engine can index them for cross-repo retrieval
+- Agent definitions (`agents/`) remain separate — executable personas vs strategic docs
+
+## Open questions
+
+1. Chunking strategy for `KaizenAgentTemplate.md` (section-aware vs whole-file)
+2. Whether Coach synthesis outputs should be ingested as derived assets
+3. Correlation with info-tech-canon profiles when both exist for one agent
+
+## Next step
+
+Dedicated workplan after WP-0004 baseline; evaluate kontextual-engine ingestion API
+stability before hard dependency.

docs/integrations/optimizer-artifact-manifest.md

@@ -0,0 +1,60 @@
+# Optimizer Evidence Artifact Manifest
+
+Package schema for `kaizen-agentic metrics publish` → **artifact-store**.
+
+## Package identity
+
+| Field | Value |
+|-------|-------|
+| `producer` | `kaizen-agentic` |
+| `retention_class` | `raw-evidence` (180d default, ADR-004 aligned) |
+| `name` | `kaizen-optimizer-<project-slug>` |
+| `subject` | project directory name (override with `--subject`) |
+
+## Files
+
+| Relative path | Source | Media type |
+|---------------|--------|------------|
+| `optimizer/analysis.json` | `.kaizen/metrics/optimizer/analysis.json` | `application/json` |
+| `optimizer/recommendations.jsonl` | `.kaizen/metrics/optimizer/recommendations.jsonl` | `application/x-ndjson` |
+
+`recommendations.jsonl` is omitted from upload when absent (e.g. insufficient samples).
+
+## Metadata (`POST /packages`)
+
+```json
+{
+  "schema": "kaizen-agentic/optimizer-evidence/v1",
+  "project": "demo-app",
+  "project_root": "/path/to/demo-app",
+  "producer": "kaizen-agentic",
+  "retention_class": "raw-evidence",
+  "retention_days": 180,
+  "optimized_at": "2026-06-18",
+  "agents": ["tdd-workflow", "coach"],
+  "files": [
+    "optimizer/analysis.json",
+    "optimizer/recommendations.jsonl"
+  ]
+}
+```
+
+## Publish workflow
+
+```bash
+# 1. Ensure optimizer has run
+kaizen-agentic metrics optimize
+
+# 2. Publish (artifact-store must be reachable)
+export ARTIFACTSTORE_API_URL=http://127.0.0.1:8000
+export ARTIFACTSTORE_API_TOKEN=<write-token>
+kaizen-agentic metrics publish --target .
+```
+
+Local-only workflows skip publish; `.kaizen/metrics/optimizer/` remains authoritative.
+
+## Related
+
+- [artifact-store ingestion API](https://github.com/coulomb/artifact-store) — `POST /packages`, `/files`, `/finalize`
+- [ADR-004](../adr/ADR-004-project-metrics-convention.md)
+- [INTEGRATION_PATTERNS.md](../INTEGRATION_PATTERNS.md)

docs/integrations/schedule-schema.md

@@ -0,0 +1,100 @@
+# `.kaizen/schedule.yml` Schema
+
+The schedule manifest declares which kaizen agents run on what cadence in an
+opted-in repo. It is the repo-local half of the scheduled-agent-execution
+contract (ADR-005). activity-core reads it (via the roster resolver) to fire
+recurring tasks; `kaizen-agentic schedule prepare` reads it indirectly by
+preparing per-agent orientation.
+
+Canonical example: [`docs/examples/.kaizen/schedule.yml`](../examples/.kaizen/schedule.yml).
+
+## Location
+
+```
+<project-root>/.kaizen/schedule.yml
+```
+
+Lives alongside `.kaizen/agents/` (memory) and `.kaizen/metrics/`. Like those,
+its presence is the **opt-in signal** for fleet scheduling.
+
+## Fields
+
+| Key | Required | Type | Default | Notes |
+|-----|----------|------|---------|-------|
+| `version` | yes | string | — | Must be `"1"` |
+| `timezone` | no | string | from ActivityDefinition | IANA tz, e.g. `Europe/Berlin` |
+| `agents` | yes | mapping | — | `agent-name → settings` |
+| `agents.<name>.cadence` | yes | enum | — | `daily` \| `weekly` \| `monthly` |
+| `agents.<name>.cron` | no | string | cadence default | 5-field cron expression |
+| `agents.<name>.enabled` | no | bool | `true` | Set `false` to declare but pause |
+
+## Example
+
+```yaml
+version: "1"
+timezone: Europe/Berlin
+agents:
+  coach:
+    cadence: weekly
+    cron: "0 9 * * 1"
+    enabled: true
+  optimization:
+    cadence: weekly
+    cron: "0 10 * * 1"
+    enabled: true
+  tdd-workflow:
+    cadence: monthly
+    enabled: false
+```
+
+## Validation
+
+```bash
+kaizen-agentic schedule validate
+```
+
+Errors are emitted with actionable messages and a non-zero exit code:
+
+- Missing or non-`"1"` `version`.
+- `agents` not a mapping, or no agents declared.
+- An agent name that is **not** installed or packaged (typo guard).
+- A `cadence` outside `daily` / `weekly` / `monthly`.
+- Duplicate agent entries.
+
+Only agents available to the project (installed under `agents/` or packaged in
+the distribution) may appear in a schedule.
+
+## Scaffolding
+
+```bash
+kaizen-agentic schedule init                 # defaults: coach + optimization weekly
+kaizen-agentic schedule init --timezone UTC  # override timezone
+kaizen-agentic schedule init --force         # overwrite existing
+kaizen-agentic schedule init --engagement coulomb-loop \
+  --agents coach,optimization --bootstrap-cadence hourly
+```
+
+The default scaffold enables `coach` and `optimization` weekly and declares
+`tdd-workflow` monthly but **disabled** (operator opts in deliberately).
+
+**Engagement bootstrap** (`--engagement`) writes customer-loop presets: hourly
+bootstrap uses `cadence: daily` with hourly `cron` overrides (coach `:15`,
+optimization `:30`). See
+[customer-engagement-playbook.md](customer-engagement-playbook.md).
+
+## Listing
+
+```bash
+kaizen-agentic schedule list        # enabled entries only
+kaizen-agentic schedule list --all  # include disabled
+```
+
+## Relationship to activity-core
+
+The `cron` field is an **optional per-repo override**. When omitted, the cadence
+maps to the default cron declared in the matching ActivityDefinition (e.g.
+`weekly-coach-orientation` fires Mon 09:00). This keeps fleet-wide timing in one
+place while letting individual repos shift their slot.
+
+See [ADR-005](../adr/ADR-005-scheduled-agent-execution.md) and
+[INTEGRATION_PATTERNS.md Pattern 2](../INTEGRATION_PATTERNS.md).

docs/integrations/state-hub-roster-fields.md

@@ -0,0 +1,64 @@
+# State Hub Roster Fields for Kaizen Scheduling (Design)
+
+**Status:** design only — implemented in `the-custodian/state-hub`, not here
+(repo boundary). This document specifies what kaizen-agentic and activity-core
+need from the hub so the State Hub team can add the fields and filter.
+
+## Problem
+
+activity-core's resolver needs to answer: *which registered repos participate in
+kaizen fleet scheduling, and where do they live on disk?* Today state-hub knows
+the canonical repo list and `host_paths` but has no notion of schedule opt-in.
+
+## Existing hub data (sufficient for v1)
+
+`GET /repos/` already returns, per repo:
+
+| Field | Use |
+|-------|-----|
+| `slug` | Canonical repo identifier (`target_repo` in tasks) |
+| `host_paths[hostname] → local_path` | Where the repo is checked out on a runner |
+| `domain` | Scope filter (e.g. `custodian`) |
+
+For **v1**, opt-in is detected **in the repo** (`.kaizen/schedule.yml` exists and
+validates). The resolver clones/reads each candidate path and checks for the
+file. No hub schema change is strictly required to ship the pilot.
+
+## Proposed hub fields (v2, optional)
+
+To let operators query eligibility **without touching every checkout**, add an
+optional repo-metadata flag:
+
+| Field | Type | Default | Meaning |
+|-------|------|---------|---------|
+| `kaizen_schedule_enabled` | bool | `false` | Operator-confirmed fleet participation |
+| `kaizen_schedule_updated_at` | timestamp | null | Last time schedule.yml was synced/seen |
+
+### Suggested filter
+
+```
+GET /repos/?kaizen_schedule_enabled=true&domain=custodian
+```
+
+Returns only schedule-eligible repos with their `host_paths`, so the resolver
+skips repos that have not opted in — cheaper than scanning every checkout.
+
+### Write path
+
+The flag is set by an operator (or a future `kaizen-agentic schedule register`
+that calls the hub). It is **advisory**: the authoritative opt-in remains the
+presence of a valid `.kaizen/schedule.yml` in the repo, re-checked by the
+resolver at run time. The flag is an index, not a source of truth.
+
+## Boundary
+
+- kaizen-agentic does **not** write these fields in WP-0006.
+- state-hub schema migration is tracked in `the-custodian`.
+- The resolver (activity-core) treats the hub flag as a pre-filter and the repo
+  file as the decision.
+
+## Related
+
+- [discover-kaizen-scheduled-repos.md](discover-kaizen-scheduled-repos.md)
+- [schedule-schema.md](schedule-schema.md)
+- [ADR-005](../adr/ADR-005-scheduled-agent-execution.md)

docs/templates/session-close-protocol.md

@@ -0,0 +1,33 @@
+# Session-Close Protocol Template
+
+Reference template for memory-enabled agents. Copy the **Session Close** block
+into `agents/agent-<name>.md` and adapt the metrics line to the agent.
+
+## Session Close
+
+1. Update `## Accumulated Findings`, `## What Worked`, and `## Watch Points` as needed.
+2. Append one line to `## Session Log`: `YYYY-MM-DD · <summary> · <outcome>`.
+3. Bump `last_updated` to today and increment `session_count` in memory frontmatter.
+4. Record session metrics (adjust flags to match outcome):
+
+```bash
+kaizen-agentic metrics record <agent-name> --success --time <seconds> --quality <0.0-1.0>
+# or on failure:
+kaizen-agentic metrics record <agent-name> --failure --time <seconds>
+```
+
+Optional: pass a full JSON record (ADR-004 schema) via stdin:
+
+```bash
+echo '{"success": true, "quality_score": 0.9, "primary_metric": {"name": "...", "value": 1.0, "target": 1.0}}' \
+  | kaizen-agentic metrics record <agent-name> --json
+```
+
+Use `--idempotency-key <session-id>` to avoid duplicate records if the close
+protocol runs more than once for the same session.
+
+## Pilot agents
+
+`tdd-workflow` is the reference implementation (WP-0003 Part 5). Other
+memory-enabled agents should adopt this block as the metrics CLI becomes available
+in their workflows.

event-types/kaizen.metrics.recorded.md

@@ -0,0 +1,65 @@
+---
+type_id: kaizen.metrics.recorded
+version: "1.0"
+publisher: kaizen-agentic
+governance: publisher-declared
+status: active
+---
+
+# kaizen.metrics.recorded
+
+## Intent
+
+Emitted when a project records agent execution metrics via
+`kaizen-agentic metrics record --emit-event`. Signals that rolling performance
+summary changed and may trigger quality-escalation ActivityDefinitions.
+
+**Owning repo:** `kaizen-agentic` — schema changes require supplier review.
+
+## When Published
+
+- CLI: `kaizen-agentic metrics record <agent> --emit-event` after successful append
+- Not emitted when append is skipped (duplicate idempotency key)
+- NATS subject: `activity.kaizen.metrics.recorded`
+
+## Attributes
+
+| Name | Type | Required | Description |
+|---|---|---|---|
+| agent | string | yes | Agent name from `metrics record <agent>` |
+| project | string | yes | Repo slug (`KAIZEN_PROJECT_SLUG` or directory basename) |
+| summary.success_rate | float | yes | Rolling success rate from `summary.json` after append |
+| summary.execution_count | integer | yes | Total execution count |
+| summary.avg_quality | float | no | Average quality score (maps from `avg_quality_score`) |
+
+## Example Payload
+
+```json
+{
+  "id": "550e8400-e29b-41d4-a716-446655440000",
+  "type": "kaizen.metrics.recorded",
+  "version": "1.0",
+  "timestamp": "2026-06-18T12:00:00Z",
+  "publisher": "kaizen-agentic",
+  "attributes": {
+    "agent": "coach",
+    "project": "kaizen-agentic",
+    "summary": {
+      "success_rate": 0.75,
+      "execution_count": 12,
+      "avg_quality": 0.81
+    }
+  }
+}
+```
+
+## Consumer Notes
+
+- **activity-core**: `event-payload` resolver binds `attributes` → `context.metrics`
+  for rules such as `flag-low-success-rate`
+- **coulomb-loop**: `low-success-rate-review` (LOOP-WP-0002) — primary reactive path
+
+## Related
+
+- `docs/integrations/kaizen-metrics-recorded-event.md`
+- `coulomb-loop/loops/quality-escalation/event-payload.md`

history/2026-06-16-ecosystem-assessment.md

@@ -0,0 +1,172 @@
+# KaizenAgentic Ecosystem Assessment
+
+**Date:** 2026-06-16
+**Compared repos:** info-tech-canon, agentic-resources, activity-core, llm-connect, identity-canon, phase-memory, artifact-store, domain-tree, kontextual-engine, tele-mcp
+**Against:** `INTENT.md`, `wiki/`, WP-0003 measurement loop plan
+
+---
+
+## Strategic Insight
+
+INTENT's vision is **distributed across the ecosystem**, not missing from a single repo:
+
+| INTENT promise | Primary owner |
+|----------------|---------------|
+| Agent definitions + deployment | kaizen-agentic |
+| Project memory + Coach | kaizen-agentic |
+| Per-agent metrics + optimizer | kaizen-agentic (WP-0003) |
+| Session capture + fleet metrics | agentic-resources (Helix Forge) |
+| Scheduled improvement triggers | activity-core |
+| Evidence retention | artifact-store |
+| Rich memory graphs | phase-memory (future) |
+| Guidance as knowledge | kontextual-engine + info-tech-canon |
+| Semantic vocabulary | info-tech-canon, identity-canon |
+| Org placement | domain-tree |
+| Runtime telemetry MCP | tele-mcp (unassessed — not cloned) |
+
+KaizenAgentic matures by **stabilizing conventions and composing adjacent services**, consistent with INTENT boundaries.
+
+---
+
+## Per-Repo Assessment
+
+### agentic-resources — P0
+
+**Role:** AgentOps / Helix Forge — Capture → Detect → Curate → Distribute → Measure on coding sessions.
+
+**Use:** Fleet-level session metrics (`session_memory/measure/`), JSONL baselines, cross-agent adapters (Claude/Codex/Grok). Complements project-scoped `.kaizen/metrics/`.
+
+**Action:** ADR-004 correlation fields; WP-0004 integration; do not re-implement session ingestion here.
+
+### activity-core — P1
+
+**Role:** Event bridge — cron/NATS → task emission.
+
+**Use:** Scheduled `metrics optimize`, retention hygiene, metrics scaffold validation after agent install.
+
+**Action:** WP-0004 ActivityDefinitions after WP-0003 Part 2.
+
+### artifact-store — P1
+
+**Role:** Artifact registry + retention gateway.
+
+**Use:** Persist optimizer `analysis.json`, recommendations, e2e evidence packages.
+
+**Action:** WP-0004 pilot registration with `raw-evidence` retention class.
+
+### info-tech-canon — P2
+
+**Role:** Markdown-first semantic canon, agent briefs, patterns, profiles.
+
+**Use:** Map KaizenAgentTemplate → canon profiles; publish per-agent briefs; validation rules for `kaizen-agentic validate`.
+
+**Action:** WP-0004 Part 4 (later phase).
+
+### phase-memory — P2
+
+**Role:** Profile-driven memory graphs (ephemeral → rigid).
+
+**Use:** Upgrade path from flat `.kaizen/agents/*/memory.md`.
+
+**Action:** Future WP after WP-0004; no WP-0003 blocker.
+
+### kontextual-engine — P2
+
+**Role:** Knowledge operations engine.
+
+**Use:** Ingest `wiki/` and `agents/` as knowledge assets; KaizenGuidance catalog runtime.
+
+**Action:** WP-0004 Part 4 (guidance pilot).
+
+### llm-connect — P3
+
+**Role:** Provider-neutral LLM adapter.
+
+**Use:** Automated Coach/optimizer narration when LLM synthesis moves beyond CLI context assembly.
+
+**Action:** Reference pattern; adopt when WP-0003+ adds LLM-powered recommendations.
+
+### domain-tree — P3
+
+**Role:** Organizational domain tree (primary + secondary bindings).
+
+**Use:** Register kaizen-agentic and agent categories in org structure.
+
+**Action:** When capability catalog matures.
+
+### identity-canon — P3
+
+**Role:** Identity/agent terminology research.
+
+**Use:** Distinguish agent persona vs instance vs session actor for "digital talent agency" framing.
+
+**Action:** Glossary alignment in wiki.
+
+### tele-mcp — TBD
+
+**Status:** On Forgejo (`coulomb/tele-mcp`); not cloned; not in State Hub registry. Name suggests telemetry MCP.
+
+**Action:** Clone and assess before integration; candidate for WP-0001 T04 telemetry adapter.
+
+---
+
+## Two-Layer Measurement Model
+
+| Layer | Scope | Owner | Storage |
+|-------|-------|-------|---------|
+| **Fleet** | Cross-repo session outcomes | agentic-resources | Helix Forge store + `measure/baselines.jsonl` |
+| **Project** | Per-agent persona performance in one repo | kaizen-agentic | `.kaizen/metrics/<agent>/executions.jsonl` |
+
+Correlation via shared fields defined in ADR-004 (`helix_session_uid`, `repo`, `success`, `tokens`, `execution_time_s`).
+
+See `wiki/EcosystemIntegration.md` for integration contracts.
+
+---
+
+## Priority Matrix
+
+| Priority | Repo | WP |
+|----------|------|-----|
+| P0 | agentic-resources | WP-0004 Part 1 |
+| P1 | activity-core | WP-0004 Part 2 |
+| P1 | artifact-store | WP-0004 Part 3 |
+| P2 | info-tech-canon, kontextual-engine, phase-memory | WP-0004 Part 4 / future |
+| P3 | llm-connect, domain-tree, identity-canon | Adopt as needed |
+| TBD | tele-mcp | Assess when cloned |
+
+---
+
+## Follow-Up Workplans
+
+- **KAIZEN-WP-0003** — measurement loop (completed 2026-06-18)
+- **KAIZEN-WP-0004** — ecosystem integration (completed 2026-06-18)
+
+---
+
+## WP-0004 Outcomes (2026-06-18)
+
+### Part 1 — Helix Forge correlation
+
+- `HELIX_SESSION_UID` env auto-merge on `metrics record`
+- `kaizen-agentic metrics correlate <uid>` read-only adapter (sqlite or stub)
+- Contract: `docs/integrations/helix-forge-correlation.md`
+- Worked example in `wiki/EcosystemIntegration.md`
+
+### Part 2 — activity-core triggers
+
+- Three ActivityDefinition reference copies under `docs/integrations/activity-definitions/`
+- Activation contract: `docs/INTEGRATION_PATTERNS.md`
+
+### Part 3 — artifact-store evidence
+
+- `kaizen-agentic metrics publish` with `raw-evidence` retention class
+- Manifest: `docs/integrations/optimizer-artifact-manifest.md`
+
+### Part 4 — Canon and knowledge (stretch)
+
+- Template mapping: `docs/integrations/canon-template-mapping.md`
+- tdd-workflow canon brief: `docs/integrations/briefs/tdd-workflow-canon-brief.md`
+- kontextual-engine spike: `docs/integrations/kontextual-wiki-ingestion-spike.md`
+
+No hard dependencies on info-tech-canon, kontextual-engine, or agentic-resources
+runtime in kaizen-agentic — integration remains contract-based.

history/2026-06-16-intent-gap-analysis.md

@@ -0,0 +1,87 @@
+# KaizenAgentic Intent Gap Analysis
+
+**Date:** 2026-06-16
+**Scope:** `INTENT.md`, `wiki/`, codebase (`agents/`, `src/kaizen_agentic/`, `docs/`, workplans)
+**Author:** kaizen-agentic session assessment
+
+---
+
+## Executive Summary
+
+Kaizen-agentic is in a **two-layer state**: the strategic/conceptual layer (`INTENT.md`, `wiki/`) is well-developed; the operational layer (agents, CLI, agency framework) is substantial but implements a **deployment and memory** product more than a **measurable continuous-improvement engine**.
+
+The largest gap: the **measurement → optimization → specification refinement loop** described in INTENT is largely unbuilt. Addressed by **KAIZEN-WP-0003** (registered 2026-06-16).
+
+---
+
+## Alignment
+
+| INTENT asset | Status |
+|--------------|--------|
+| Mission and conceptual model | `wiki/` established |
+| KaizenAgent definition template | `wiki/KaizenAgentTemplate.md` — not enforced in agents |
+| Meta-optimizer concept | `wiki/AgentKaizenOptimizer.md` + `agent-optimization.md` — no data pipeline |
+| Idempotent/measurable principles | Documented; not in agent implementations |
+| Codebase improvement guidance | `wiki/KaizenGuidance.md` — vision only |
+| Prompts/experiments/mantras | `wiki/KaizenPrompting.md` — not operationalized |
+| Product/pricing/brand | `wiki/` complete |
+| Agency memory + Coach | WP-0002 shipped |
+| CLI deployment | Functional (21 agents) |
+
+---
+
+## Critical Gaps
+
+### 1. Kaizen loop not closed
+
+INTENT requires evidence-based refinement with before/after deltas. Reality: `OptimizationLoop` exists but is unwired; no `.kaizen/metrics/`; WP-0001 telemetry unstarted.
+
+### 2. Agent template not enforced
+
+Agents use minimal YAML frontmatter; `wiki/KaizenAgentTemplate.md` (metrics, idempotency, testing, evolution) is reference only.
+
+### 3. KaizenGuidance unbuilt
+
+No guide catalog, manifests, codemods, or Parse→Measure pipeline.
+
+### 4. Coach vs optimizer not integrated
+
+Qualitative memory (Coach) and quantitative optimization (optimizer) are separate paths.
+
+### 5. Agent implementation boundary undeclared
+
+INTENT says repo should not own all concrete agent implementations; 21 agents live here as reference fleet — interim state needs explicit policy.
+
+---
+
+## Design Principles Scorecard
+
+| Principle | Status |
+|-----------|--------|
+| Continuous Improvement | Partial (memory; no automated refinement) |
+| Measurable by Default | Gap |
+| Idempotent Operations | Gap |
+| Evidence over Intuition | Gap |
+| Separation of Concerns | Partial |
+| Composable Capabilities | Gap |
+| Human-Readable + Machine-Executable | Gap (guidance) |
+| Rollback-Ready Evolution | Partial |
+| Compounding Value | Partial (memory only) |
+
+---
+
+## Remediation Sequence
+
+1. **WP-0003** — metrics convention, CLI, optimizer wiring, Coach bridge (active)
+2. **WP-0004** — ecosystem integration (agentic-resources, activity-core, artifact-store)
+3. Future — KaizenGuidance catalog, phase-memory upgrade, full template conformance
+
+---
+
+## Related Artifacts
+
+- `SCOPE.md` — updated 2026-06-16
+- `workplans/kaizen-agentic-WP-0003-measurement-loop.md`
+- `history/2026-06-16-ecosystem-assessment.md`
+- `wiki/EcosystemIntegration.md`
+- `docs/adr/ADR-004-project-metrics-convention.md`

history/README.md

@@ -0,0 +1,11 @@
+# History
+
+Persisted assessments, gap analyses, and ecosystem reviews for KaizenAgentic.
+
+| Date | Document | Summary |
+|------|----------|---------|
+| 2026-06-16 | [2026-06-16-intent-gap-analysis.md](2026-06-16-intent-gap-analysis.md) | INTENT.md vs implementation gaps; remediation sequence |
+| 2026-06-16 | [2026-06-16-ecosystem-assessment.md](2026-06-16-ecosystem-assessment.md) | Cross-repo comparison (10 ecosystem repos) |
+
+These files are point-in-time records. Living conventions live in `INTENT.md`,
+`SCOPE.md`, `wiki/`, and `docs/adr/`.

pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "kaizen-agentic"
-version = "1.0.2"
+version = "1.4.0"
 description = "AI agent development framework embracing continuous improvement (kaizen)"
 readme = "README.md"
 license = {file = "LICENSE"}
@@ -32,6 +32,9 @@ dependencies = [
 ]
 
 [project.optional-dependencies]
+events = [
+    "nats-py>=2.6.0",
+]
 dev = [
     "pytest>=6.0.0",
     "pytest-cov>=4.0.0",
@@ -135,4 +138,4 @@ exclude_lines = [
 
 [tool.flake8]
 max-line-length = 88
-extend-ignore = ["E203", "W503"]
+extend-ignore = ["E203", "W503"]

registry/README.md

@@ -0,0 +1,12 @@
+# Capability Registry
+
+Markdown-first capability index for federation and reuse planning.
+
+## Authoring
+
+1. Copy a capability entry template (see reuse-surface `templates/capability-entry.template.md`).
+2. Add the row to `indexes/capabilities.yaml`.
+3. Run `reuse-surface validate` from a checkout with the CLI installed.
+4. Merge to `main` and verify publish with `reuse-surface establish --publish-check`.
+
+Federation contract: reuse-surface `docs/RegistryFederation.md`.

registry/indexes/capabilities.yaml

@@ -0,0 +1,4 @@
+version: 1
+updated: '2026-06-16'
+domain: helix_forge
+capabilities: []

src/kaizen_agentic/__init__.py

@@ -9,13 +9,14 @@ It also includes a comprehensive agent distribution system for sharing
 specialized agents across projects via CLI tools and package management.
 """
 
-__version__ = "1.0.2"
+__version__ = "1.4.0"
 __author__ = "Kaizen Agentic Team"
 
 from .core import Agent, AgentConfig
 from .optimization import OptimizationLoop, PerformanceMetrics
 from .registry import AgentRegistry, AgentDefinition, AgentCategory
 from .installer import AgentInstaller, ProjectInitializer, InstallationConfig
+from .metrics import MetricsStore
 
 __all__ = [
     "Agent",
@@ -28,4 +29,5 @@ __all__ = [
     "AgentInstaller",
     "ProjectInitializer",
     "InstallationConfig",
+    "MetricsStore",
 ]

src/kaizen_agentic/agent_docs.py

@@ -0,0 +1,73 @@
+"""Render and idempotently upsert the project ``## Installed Agents`` section.
+
+Single source of truth for the agent documentation block written into a
+project's ``CLAUDE.md``. Both :class:`~kaizen_agentic.installer.AgentInstaller`
+and the ``kaizen-agentic docs generate`` command reuse these helpers so the
+section is produced and replaced the same way everywhere — and, critically,
+**idempotently**: regenerating N times yields the same output as once.
+"""
+
+from __future__ import annotations
+
+import re
+from typing import Dict, Iterable, List
+
+from .registry import AgentDefinition
+
+SECTION_HEADING = "## Installed Agents"
+SECTION_FOOTER = (
+    "Use these agents by referencing them in your Claude Code interactions."
+)
+
+# Match the Installed Agents block up to the next *top-level* heading (``\n## ``,
+# with a trailing space so ``### Subsection`` headings inside the block do not
+# terminate the match) or end-of-file. The previous ``(?=##|\Z)`` form stopped
+# at the first ``### Category`` subheading and so duplicated the block on every
+# run (WP-0007 T01).
+_SECTION_RE = re.compile(r"## Installed Agents.*?(?=\n## (?!#)|\Z)", re.DOTALL)
+
+
+def render_installed_agents_section(agents: Iterable[AgentDefinition]) -> str:
+    """Render the ``## Installed Agents`` markdown block from agent metadata.
+
+    Agents are grouped by category in first-seen order. The returned string is
+    newline-terminated and contains no trailing top-level heading, so it can be
+    spliced in front of any following section.
+    """
+    lines: List[str] = [
+        SECTION_HEADING,
+        "",
+        "This project includes the following specialized agents:",
+        "",
+    ]
+
+    categories: Dict[str, List[AgentDefinition]] = {}
+    for agent in agents:
+        categories.setdefault(agent.category.value, []).append(agent)
+
+    for category, members in categories.items():
+        lines.append(f"### {category.replace('-', ' ').title()}")
+        lines.append("")
+        for agent in members:
+            lines.append(f"- **{agent.name}**: {agent.description}")
+        lines.append("")
+
+    lines.append(SECTION_FOOTER)
+    lines.append("")
+    return "\n".join(lines)
+
+
+def upsert_installed_agents_section(content: str, section: str) -> str:
+    """Return ``content`` with its Installed Agents block replaced or appended.
+
+    Idempotent: if ``content`` already contains the block, exactly that block is
+    replaced (never duplicated); otherwise the section is appended. ``section``
+    is normalised to end with a single trailing blank line.
+    """
+    section = section.rstrip() + "\n"
+
+    if SECTION_HEADING in content:
+        return _SECTION_RE.sub(lambda _m: section, content, count=1)
+
+    separator = "" if content.endswith("\n\n") or not content else "\n"
+    return content + separator + section

src/kaizen_agentic/data/agents/agent-claude-documentation.md

@@ -1,6 +1,7 @@
 ---
-name: claude-expert
+name: claude-documentation
 description: Specialized assistant for Claude and Claude Code documentation, features, and best practices
+category: documentation
 ---
 
 ## Instructions

src/kaizen_agentic/data/agents/agent-coach.md

@@ -0,0 +1,184 @@
+---
+name: coach
+description: Coaching meta-agent that reads all agent memories in a project and synthesises cross-agent briefs and new-agent orientations
+category: meta
+memory: enabled
+---
+
+# Coach Agent
+
+## Role
+
+You are the **kaizen-agentic Coach** — a meta-agent that observes, synthesises,
+and advises. You do not perform domain work (coding, testing, infrastructure).
+Your sole purpose is to read across the accumulated memories of all agents in a
+project and produce useful, targeted briefs.
+
+You are invoked via:
+```
+kaizen-agentic memory brief <agent-name>
+```
+
+Or directly by the operator: *"Coach, brief the sys-medic agent on this project"*
+or *"Coach, what patterns have you observed across all agents?"*
+
+---
+
+## What You Do
+
+### 1. Cross-Agent Synthesis
+
+Read all `.kaizen/agents/*/memory.md` files in the current project. Identify:
+
+- **Shared patterns**: themes that appear across multiple agents
+  (e.g. "three agents flagged missing test coverage as a risk")
+- **Cross-domain risks**: signals in one agent's memory that should inform
+  another (e.g. infrastructure instability flagged by sys-medic → tdd-workflow
+  should account for flaky environments)
+- **Resource or architectural signals**: recurring mentions of specific files,
+  modules, services, or systems across agents
+- **Contradictions or gaps**: where agents hold conflicting assumptions or where
+  no agent has coverage
+
+### 2. New-Agent Orientation
+
+When asked to brief a specific agent about to be deployed for the first time:
+
+1. Read all existing agent memories in the project
+2. Filter for what is relevant to the incoming agent's domain
+3. Produce a targeted orientation brief covering:
+   - **Project context**: what kind of project this is, key constraints
+   - **What to know first**: the most important facts for this agent
+   - **Watch points**: risks or pitfalls flagged by other agents that are relevant
+   - **What has worked**: successful approaches in adjacent domains
+   - **Open threads**: unresolved items from other agents that may interact with
+     this agent's work
+
+### 3. Fleet Health Overview
+
+When asked for a fleet overview:
+
+- Summarise the health of the agent fleet: which agents are active, stale, or
+  missing from the project
+- Flag agents with high `session_count` and still-open `## Open Threads`
+- Identify agents whose memories suggest overlapping concerns
+- Recommend whether any memory files should be reviewed or reset
+
+---
+
+## How to Read Agent Memory Files
+
+Memory files live at `.kaizen/agents/<name>/memory.md` relative to the project
+root. Each follows ADR-002 structure:
+
+```
+## Project Context      ← agent's understanding of the project
+## Accumulated Findings ← patterns and recurring issues
+## What Worked         ← validated approaches
+## Watch Points        ← risks and traps
+## Open Threads        ← unresolved items
+## Session Log         ← chronological session summaries
+```
+
+When synthesising, weight `## Watch Points` and `## Open Threads` most heavily —
+these are the signals most likely to be actionable for another agent.
+
+### Project metrics (ADR-004)
+
+Quantitative performance data lives at `.kaizen/metrics/<agent>/summary.json`.
+`kaizen-agentic memory brief <agent>` includes a `## Performance Summary` block
+when metrics exist.
+
+When synthesising orientations:
+
+- Combine qualitative memory with quantitative trends (success rate, quality,
+  execution time, trend arrows)
+- Flag agents with declining success rate or quality trends
+- Cross-reference metrics with `## Watch Points` — do metrics confirm or
+  contradict qualitative findings?
+- Note when an agent has memory but no metrics (incomplete session-close protocol)
+
+Fleet optimizer output at `.kaizen/metrics/optimizer/analysis.json` provides
+project-wide analysis from `kaizen-agentic metrics optimize`.
+
+---
+
+## Output Format
+
+### Cross-agent brief
+
+```
+## Cross-Agent Brief — <project name>
+Generated: <date>
+Agents with memory: <list>
+
+### Shared Patterns
+<bullet list of themes appearing across ≥2 agents>
+
+### Cross-Domain Risks
+<risks from one domain relevant to others>
+
+### Open Threads (fleet-wide)
+<unresolved items that span or affect multiple agents>
+
+### Fleet Health
+<which agents are active/stale, any concerning signals>
+```
+
+### New-agent orientation
+
+```
+## Orientation Brief for: <agent-name>
+Project: <project name>
+Generated: <date>
+Sources: <which agent memories were read>
+
+### Performance Summary
+<from .kaizen/metrics/<agent>/ when available — success rate, quality, trends>
+
+### What to Know First
+<3–5 most important facts for this agent>
+
+### Watch Points
+<risks relevant to this agent's domain>
+
+### What Has Worked
+<approaches validated by other agents that apply here>
+
+### Open Threads You May Encounter
+<items from other agents that may intersect with your work>
+```
+
+---
+
+## Behaviour Boundaries
+
+- **Do not** modify agent memory files
+- **Do not** perform any domain-specific work (coding, testing, diagnosis)
+- **Do not** make decisions — synthesise and advise only
+- **If no memories exist**: say so clearly and offer to help initialise them
+- **If asked about a specific agent not present**: note the gap
+
+---
+
+## Coach's Own Memory
+
+The coach maintains `.kaizen/agents/coach/memory.md` covering:
+
+- Fleet-level patterns observed over time
+- How the agent population in this project has evolved
+- Meta-observations about how well the memory convention is being followed
+- Recurring gaps or blind spots in the agent fleet
+
+### Session Start
+
+1. Check for `.kaizen/agents/coach/memory.md`.
+2. If present, read it — prior fleet observations provide context for the current synthesis.
+3. Scan `.kaizen/agents/*/memory.md` to build the current fleet picture.
+
+### Session Close
+
+1. Update `## Accumulated Findings` with new fleet-level patterns.
+2. Note any new agents added or memory files reset.
+3. Append one line to `## Session Log`: `YYYY-MM-DD · <brief requested for> · <key finding>`.
+4. Bump `last_updated` and `session_count`.