Reference InfoTechCanon identity model in integration guidance

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a070b5-4994-7271-bd8b-7c3dbcedec4b

.custodian-brief.md

@@ -1,8 +1,8 @@
 <!-- custodian-brief: generated by fix-consistency — do not edit manually -->
 # Custodian Brief — kaizen-agentic
 
-**Domain:** infotech
-**Last synced:** 2026-07-16 10:48 UTC
+**Domain:** agents  
+**Last synced:** 2026-09-05 23:33 UTC  
 **State Hub:** http://127.0.0.1:8000 *(adjust if running on a remote machine)*
 
 ## Active Workstreams
@@ -13,6 +13,6 @@
 ## MCP Orientation (when available)
 
 If the state-hub MCP server is reachable, call:
-`get_domain_summary("infotech")`
+`get_domain_summary("agents")`
 This provides richer cross-domain context.
 If the MCP call fails, use this file as your orientation source.

.forgejo/ISSUE_TEMPLATE/config.yaml

@@ -0,0 +1,8 @@
+blank_issues_enabled: false
+contact_links:
+  - name: Feedback guide
+    url: https://forgejo.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://forgejo.coulomb.social/coulomb/kaizen-agentic/src/branch/main/CONTRIBUTING.md
+    about: Development workflow and code standards

.forgejo/workflows/ci.yml

@@ -50,4 +50,4 @@ jobs:
 
       - name: Run tests
         working-directory: repo
-        run: pytest tests/ -q --ignore=tests/test_cli_error_handling.py
+        run: pytest tests/ -q

.gitea/ISSUE_TEMPLATE/config.yaml

@@ -1,8 +0,0 @@
-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

.repo-classification.yaml

@@ -11,7 +11,6 @@ repo_classification:
   - infotech
   capability_tags:
   - orchestration
-  - automation
   - coordination
   - knowledge
   - documentation

AGENTS.md

@@ -19,7 +19,7 @@ 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` |
+| Remote (railiance01, in-cluster) | `http://10.43.68.154:8000` |
 | Optional local edge relay | http://127.0.0.1:18080 |
 
 When an operator has enabled the edge relay, set API_BASE to the relay URL.

CONTRIBUTING.md

@@ -33,7 +33,7 @@ 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.
+for the Forgejo PyPI `--extra-index-url` install path.
 
 **Maintainers (release):** `make agents-sync-package` before tagging when `agents/` changes;
 `make package-check` and the pre-tag checklist in `docs/PACKAGE_RELEASE.md`.
@@ -43,7 +43,7 @@ for Gitea PyPI credentials and `--extra-index-url` install paths.
 ### Project Structure
 This repository follows PythonVibes best practices:
 - `src/kaizen_agentic/` - Core framework source code
-- `agents/` - Specialized agent definitions (17+ agents)
+- `agents/` - Specialized agent definitions (20 agents)
 - `tests/` - Comprehensive test suite
 - `workplans/` - Active workstreams and tasks (ADR-001)
 - `CHANGELOG.md` - Version history (Keep a Changelog format)
@@ -78,7 +78,7 @@ This repository follows PythonVibes best practices:
 - **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`
+- **CI**: Forgejo Actions workflow `.forgejo/workflows/ci.yml` runs on push/PR to `main`
 
 ### Agent Development Standards
 For contributing new agents or improving existing ones:
@@ -136,7 +136,7 @@ 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)
+- **Templates:** `.forgejo/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`.
@@ -161,7 +161,7 @@ When reporting bugs, please include:
 
 ## Agent-Assisted Development
 
-This repository includes 17+ specialized agents to assist with development:
+This repository includes 20 specialized agents to assist with development:
 - Use `keepaChangelog` for CHANGELOG.md updates
 - Use `project-assistant` for workplan and session orientation
 - Use `contributing-keeper` for this file maintenance
@@ -178,7 +178,7 @@ We follow continuous improvement principles:
 
 ### Communication
 - Be respectful and constructive in all interactions
-- Use GitHub issues and discussions for project-related communication
+- Use Forgejo issues for project-related communication
 - Share knowledge and help other contributors
 - Follow the project's code of conduct
 

INTENT.md

@@ -80,6 +80,3 @@ At maturity, it should provide enough structure for a team to define, deploy, me
 `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

LICENSE

@@ -1,18 +1,151 @@
-MIT License
+# Target Revenue Source License
 
-Copyright (c) 2025 CoulombCore
+**Version 1.0, Candidate 1 (V1C1)**
 
-Permission is hereby granted, free of charge, to any person obtaining a copy of this software and 
-associated documentation files (the "Software"), to deal in the Software without restriction, including 
-without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 
-copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the 
-following conditions:
+---
 
-The above copyright notice and this permission notice shall be included in all copies or substantial 
-portions of the Software.
+> **PRELIMINARY CANDIDATE — SUBJECT TO CHANGE — NOT FINAL**
+>
+> This repository is governed by the Target Revenue Source License
+> (TRSL), Version 1, Candidate 1. This is the framework's first working
+> candidate, adopted as the org's preliminary operating license across
+> all repos (maintainer decision, 2026-07-29) during the build/alpha
+> stage — see `SCOPE.md` §1 and Appendix A of the canonical text (link
+> below) for the alpha/beta risk-acceptance decision this reflects and
+> what it does and does not mean. Full specialist legal review is
+> explicitly deferred until the framework moves out of beta.
+>
+> **Canonical source, full candidate-status banner, and Appendix A
+> (non-normative candidate notes tracking every open item):** the
+> `coulomb` org's `target-revenue` repository,
+> `specs/TargetRevenueSourceLicense-V1C1.md` — this file is the operative
+> legal text (Preamble through Section 11) only; the canonical document
+> is authoritative if this copy and that document ever diverge.
 
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT 
-LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO 
-EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER 
-IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE 
-USE OR OTHER DEALINGS IN THE SOFTWARE.
+---
+
+## Preamble
+
+This Target Revenue Source License ("**License**") governs the Software identified in the applicable Phase Manifest. It implements the Target Revenue Framework: a defined development Phase accumulates Development Credit and Remission Credit against an immutable Initial Target until the Milestone Release automatically and irrevocably converts to a declared permissive Future License.
+
+Commercial beneficiaries fund the creation and early availability of a software improvement; once the declared target is satisfied, the governed release becomes permissively open source.
+
+## 1. Definitions
+
+Capitalized terms used in this License have the meanings given below. Where a term is also defined in the Phase Manifest or Target Ledger for a specific Phase, the Phase Manifest and Target Ledger govern the *values* (amounts, dates, identifiers) and this License governs the *legal effect* of those values — the two must not be read as conflicting definitions of the same concept.
+
+**"Commercial Entitlement"** means a right, purchased or otherwise granted under a Commercial Use Agreement, to make Commercial Use of the Software during a Phase.
+
+**"Commercial Use"** means billing, invoicing, or otherwise charging any customer a fee, subscription, license fee, or other consideration for or in connection with use of the Software, at any time before the Conversion Event for the applicable Phase, regardless of whether the person or organization billed would otherwise qualify for Noncommercial Use. Commercial Use occurs by virtue of such billing alone, whether or not the resulting payment is registered with the Trust Service; in particular, billing a customer for pre-conversion use of the Software without recording the corresponding payment in the applicable Phase's Target Ledger is Commercial Use without a valid Commercial Entitlement — a violation of Section 3, addressed under Section 7 and, where applicable, the Enforcement Network described in the canonical repository's `specs/EnforcementNetworkConcept.md`.
+
+**"Commercial Use Agreement"** means the separate agreement, referenced by the applicable Phase Manifest, under which a Commercial Entitlement is purchased or granted. This License does not itself set pricing, metering, or payment terms — those are governed by the Commercial Use Agreement.
+
+**"Conversion Event"** means the moment the Outstanding Target for a Phase reaches zero, as computed from the Phase Manifest and Target Ledger per the Target Ledger Specification. The Conversion Event occurs automatically and is not conditioned on any declaration, attestation, or other act by the Licensor or any Trust Service.
+
+**"Development Credit"** means the portion of a collected and settled payment explicitly allocated toward satisfying the Initial Target of a specific Phase, as recorded in that Phase's Target Ledger.
+
+**"Future License"** means the permissive license identified in the applicable Phase Manifest, being either the MIT License or the Apache License, Version 2.0, which applies to the Milestone Release upon the Conversion Event.
+
+**"Initial Target"** means the immutable monetary target declared for a Phase in its Phase Manifest.
+
+**"Licensor"** means **Binky Hedgehog GmbH**, the party that publishes the Phase Manifest and holds the rights necessary to grant this License and the Future License for the Milestone Release.
+
+**"Milestone Release"** means the precisely identified software release designated in the applicable Phase Manifest, identified by an immutable source revision, release artifact, or cryptographic digest.
+
+**"Noncommercial Use"** means use of the Software for personal purposes, private study, hobby or amateur projects; use by any charitable organization, educational institution, public research organization, or government institution acting in a non-revenue-generating capacity; or other use of a materially similar character.
+
+**"Outstanding Target"** means, at any time, `max(0, Initial Target − cumulative Development Credit − cumulative Remission Credit)` for a Phase, as computed from that Phase's Target Ledger.
+
+**"Phase"** means a bounded development undertaking governed by one Initial Target, one Milestone Release, one degeneration policy, and one Future License declaration, as declared in a Phase Manifest.
+
+**"Phase Manifest"** means the published, immutable declaration identifying a Phase, its Milestone Release, Initial Target, Future License, degeneration policy, and Target Ledger location, as specified in the Phase Manifest Specification.
+
+**"Remission Credit"** means a transparent, non-revenue reduction of a Phase's Outstanding Target, generated under that Phase's published degeneration policy and recorded in the Target Ledger.
+
+**"Settled Payment"** means a payment that has cleared through its payment processor and is no longer subject to reversal in the ordinary course (chargeback, dispute, or equivalent), as further specified by the applicable Commercial Use Agreement or monetization extension.
+
+**"Software"** means the source code, object code, and associated documentation of the Milestone Release identified in the applicable Phase Manifest.
+
+**"Target Ledger"** means the append-only record of Development Credit, Remission Credit, and correction entries for a Phase, as specified in the Target Ledger Specification.
+
+**"You"** or **"Licensee"** means the individual or entity exercising rights under this License.
+
+## 2. Grant of Rights for Noncommercial Use
+
+Subject to the terms of this License, the Licensor grants You a worldwide, royalty-free, non-exclusive license, during the applicable Phase, to:
+
+(a) use, reproduce, and study the Software for any Noncommercial Use;
+
+(b) modify the Software and create derivative works of it for any Noncommercial Use; and
+
+(c) redistribute the Software and Your modifications, in source or object form, for any Noncommercial Use, provided that You include this License, unmodified, with any such redistribution, and that You do not remove or alter any copyright, patent, trademark, or attribution notices contained in the Software.
+
+This grant does not extend to Commercial Use. Commercial Use requires a Commercial Entitlement under Section 3.
+
+## 3. Commercial Use
+
+You may not make Commercial Use of the Software during the applicable Phase unless You hold a valid, current Commercial Entitlement under a Commercial Use Agreement with the Licensor covering the applicable Phase. A Commercial Entitlement granted under one Phase's Commercial Use Agreement does not extend to a later Phase's Milestone Release unless the Commercial Use Agreement expressly says so.
+
+This Section 3 states the existence and boundary of the commercial-use restriction. It does not itself set pricing, invoicing, metering, audit rights, or payment terms — those are governed exclusively by the applicable Commercial Use Agreement.
+
+## 4. Patent License
+
+Subject to the terms of this License, each contributor to the Software grants You, during the applicable Phase and solely to the extent of rights granted under Sections 2 and 3, a perpetual (subject to the termination below), worldwide, non-exclusive, no-charge, royalty-free patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Software, limited to those patent claims licensable by that contributor that are necessarily infringed by their contribution(s) alone or by combination of their contribution(s) with the Software.
+
+If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Software or a contribution incorporated within it constitutes direct or contributory patent infringement, then any patent licenses granted to You under this Section 4 for the Software shall terminate as of the date such litigation is filed.
+
+## 5. Automatic Conversion to the Future License
+
+**5.1 Automatic effect.** Upon the Conversion Event for a Phase, the rights and restrictions in Sections 3 (Commercial Use) of this License, as they apply to that Phase's Milestone Release, terminate automatically. In their place, the Milestone Release is licensed under the Future License identified in that Phase's Phase Manifest, effective as of the Conversion Event, without any further act, declaration, or attestation required by the Licensor, any Trust Service, or any other party.
+
+**5.2 Irrevocability.** Once a valid Conversion Event has occurred for a Phase, no subsequent refund, chargeback, accounting correction, dispute, or termination of this License for an unrelated breach shall revoke, suspend, or otherwise impair the Future License grant for that Phase's Milestone Release. Any shortfall or dispute arising after a Conversion Event is a commercial or accounting matter between the relevant parties and does not reinstate a commercial-use restriction over already-converted Software.
+
+**5.3 Prior freedom preserved.** A later Phase covering subsequent improvements to the Software does not restrict, withdraw, or otherwise affect the rights granted under the Future License for an earlier Phase's already-converted Milestone Release.
+
+**5.4 Evidence, not cause.** A Trust Service may publish a Conversion Attestation documenting a Conversion Event. Such an attestation is evidence that the Conversion Event occurred; it is not a condition of, and its absence or delay does not postpone, the automatic effect described in Section 5.1. Any person may independently verify whether a Conversion Event has occurred directly from the Phase Manifest and Target Ledger.
+
+## 6. Successive Phases
+
+The Licensor may declare a new Phase covering subsequent improvements to the Software following a Milestone Release's Conversion Event. Each Phase is independently governed by its own Phase Manifest, Initial Target, degeneration policy, and Target Ledger. Nothing in a later Phase's Phase Manifest may be construed to reduce or withdraw rights already granted under Section 5 for an earlier Phase's Milestone Release.
+
+## 7. Term and Termination
+
+**7.1 Term.** This License applies to the Software for the duration of the applicable Phase, and, for the Milestone Release, indefinitely following that Phase's Conversion Event under the Future License.
+
+**7.2 Termination for breach.** If You breach Section 3 (Commercial Use) or Section 2(c) (redistribution notice requirement), the Licensor may terminate this License as to You. Before such termination becomes effective, the Licensor shall provide You written notice of the breach; if You cure the breach within thirty (30) days of that notice, this License continues in effect. A second breach of the same provision within twelve (12) months may be terminated immediately without a further cure opportunity.
+
+**7.3 Effect of termination.** Termination under this Section 7 affects only Your rights under Sections 2 and 3 for the Phase in which the breach occurred. It does not affect any rights already vested under Section 5 (Automatic Conversion) for a Milestone Release whose Conversion Event has already occurred, per Section 5.2.
+
+**7.4 Public record of breach and resolution.** The Licensor shall cause the Trust Service to publish, as part of the public record for the affected Phase, notice of: (a) any breach notice issued under Section 7.2, stating the general nature of the breach and the date of notice; (b) whether the breach was cured within the applicable cure period, and the date of cure; and (c) any termination determination made under this Section 7, including its effective date and scope. This public record exists to give the ecosystem a transparent, verifiable conformity signal for the Phase, distinct from and in addition to the Development Credit and Remission Credit facts already published under Section 5.4 and the Target Ledger Specification.
+
+A breach that You dispute, and that has not been finally determined, shall be recorded as **alleged**; it shall be recorded as **determined** only once the cure period has run without cure, or the dispute has been resolved against You under the applicable Commercial Use Agreement's dispute process, if any. The Trust Service shall update the record promptly upon resolution in either direction. Recording an alleged or determined breach under this Section 7.4 is a ministerial act of publishing the Licensor's determination (or a dispute process's outcome); it does not give the Trust Service discretionary authority to decide whether a breach occurred, consistent with Section 5.4's evidence-not-cause principle.
+
+Whether, and under what conditions, the public record identifies a Commercial Entitlement holder by name is governed exclusively by the applicable Commercial Use Agreement, which the Licensor and that Commercial Entitlement holder negotiate and agree to directly. This License does not itself set a naming default. Where no Commercial Use Agreement addresses the question, or where the affected party has no Commercial Use Agreement at all (for example, a Section 2(c) breach by a Noncommercial Use licensee), the public record states the Phase and breach category only, without naming the party.
+
+## 8. Disclaimer of Warranty
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT. THE LICENSOR DOES NOT WARRANT THAT THE SOFTWARE WILL BE ERROR-FREE OR THAT ANY PHASE WILL REACH ITS CONVERSION EVENT.
+
+## 9. Limitation of Liability
+
+IN NO EVENT SHALL THE LICENSOR OR ANY CONTRIBUTOR BE LIABLE FOR ANY CLAIM, DAMAGES, OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT, OR OTHERWISE, ARISING FROM, OUT OF, OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE, EXCEPT TO THE EXTENT SUCH LIMITATION IS PROHIBITED BY APPLICABLE LAW.
+
+## 10. Trademarks
+
+This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary attribution.
+
+## 11. General Provisions
+
+**11.1 Governing law and venue.** Adopted for alpha/beta 2026-07-29: disputes arising under this License shall be resolved by binding arbitration, seated at a neutral, arbitration-mature venue (Singapore or London are the two candidates concretely supported by current research), rather than by litigation in a national court. The specific arbitral institution and substantive governing law remain a per-deployment blank pending final selection; they are not fixed by this candidate. See the canonical repository's `history/260729-TRSL-Jurisdiction-Synthesis.md` §2.
+
+**11.2 Severability.** If any provision of this License is held unenforceable, the remaining provisions remain in full force, and the unenforceable provision shall be reformed to the minimum extent necessary to make it enforceable.
+
+**11.3 No waiver.** Failure to enforce any provision of this License is not a waiver of future enforcement of that or any other provision.
+
+**11.4 Entire agreement (as to licensing).** This License, together with the applicable Phase Manifest and, where applicable, the Commercial Use Agreement, constitutes the entire agreement between You and the Licensor regarding the Software's licensing terms. Operations, service, and consulting arrangements are governed by separate agreements, if any, and are not part of this License.
+
+**11.5 Definitions control.** Marketing materials, documentation, or other non-normative communications about the Software must not describe pre-Conversion-Event Software as "Open Source," "free software," or "open core." Pre-conversion Noncommercial Use is **source-available**; pre-conversion Commercial Use requires a **Commercial Entitlement**; only post-conversion Software may be described as Open Source, under the Future License.
+
+---
+
+**No Phase is currently declared for this repository under this License.** Until a Phase Manifest is published and registered with the Trust Service for a Milestone Release in this repository, Sections 2–7 above have no operative subject matter here — this License establishes the governing framework in advance of that declaration, consistent with the org-wide rollout decision recorded in `target-revenue`'s `workplans/TREV-WP-0008-governance-and-pilot-rollout.md`.

Makefile

@@ -1,14 +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-sync-package agents-install-cli release-check release-prepare release-test release-publish publish-gitea package-check 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-forgejo 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/
+FORGEJO_PACKAGE_OWNER ?= coulomb
+FORGEJO_PYPI_REPOSITORY_URL ?= https://forgejo.coulomb.social/api/packages/$(FORGEJO_PACKAGE_OWNER)/pypi
+FORGEJO_PYPI_SIMPLE_URL ?= https://forgejo.coulomb.social/api/packages/$(FORGEJO_PACKAGE_OWNER)/pypi/simple/
 
 # Default target
 help:
@@ -48,10 +48,10 @@ help:
 	@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 "  publish-forgejo - Publish dist/* to the Forgejo PyPI registry"
 	@echo "  release-test    - Test publication workflow using TestPyPI"
 	@echo "  release-publish - Publish to production PyPI (pypi.org)"
-	@echo "  release-finalize - Post-release tasks (tags, GitHub release, documentation)"
+	@echo "  release-finalize - Post-release tasks (tags, Forgejo release, documentation)"
 	@echo "  release-rollback - Emergency rollback procedures"
 	@echo ""
 	@echo "Development:"
@@ -970,7 +970,7 @@ release-prepare: release-check clean
 	ls -la dist/ | grep "$$VERSION" || echo "   • Package files:"; ls -la dist/; \
 	echo ""; \
 	echo "💡 Next steps:"; \
-	echo "   • Run 'make publish-gitea' for Coulomb Gitea PyPI"; \
+	echo "   • Run 'make publish-forgejo' for Forgejo PyPI"; \
 	echo "   • Run 'make release-test' to test publication on TestPyPI"; \
 	echo "   • Run 'make release-publish' for pypi.org (when configured)"
 
@@ -979,15 +979,15 @@ 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
+# Publish to the Forgejo PyPI registry
+publish-forgejo: package-check
 ifndef TWINE_USERNAME
-	$(error TWINE_USERNAME is required (e.g. export TWINE_USERNAME=<gitea-user>))
+	$(error TWINE_USERNAME is required (e.g. export TWINE_USERNAME=<forgejo-user>))
 endif
 ifndef TWINE_PASSWORD
-	$(error TWINE_PASSWORD is required (e.g. export TWINE_PASSWORD=$$GITEA_API_TOKEN))
+	$(error TWINE_PASSWORD is required (e.g. export TWINE_PASSWORD=$$FORGEJO_PYPI_TOKEN))
 endif
-	$(VENV_PYTHON) -m twine upload --repository-url "$(GITEA_PYPI_REPOSITORY_URL)" dist/*
+	$(VENV_PYTHON) -m twine upload --repository-url "$(FORGEJO_PYPI_REPOSITORY_URL)" dist/*
 
 # Test publication workflow using TestPyPI
 release-test: release-prepare
@@ -1034,7 +1034,7 @@ release-publish: release-check
 	echo "   • Generate API token"; \
 	echo "   • Store in ~/.pypirc or use keyring"
 
-# Post-release tasks (tags, GitHub release, documentation)
+# Post-release tasks (tags, Forgejo release, documentation)
 release-finalize: $(VENV)/bin/activate
 	@echo "🏁 Finalizing release..."
 	@echo ""
@@ -1050,16 +1050,16 @@ release-finalize: $(VENV)/bin/activate
 		echo "    ✅ Tag created"; \
 	fi; \
 	echo ""; \
-	echo "  • GitHub Release:"; \
+	echo "  • Forgejo Release:"; \
 	echo "    💡 Manual steps required:"; \
 	echo "       1. Push tags: git push origin v$$VERSION"; \
-	echo "       2. Create GitHub release at:"; \
-	echo "          https://github.com/kaizen-agentic/kaizen-agentic/releases/new"; \
+	echo "       2. Create Forgejo release at:"; \
+	echo "          https://forgejo.coulomb.social/coulomb/kaizen-agentic/releases/new"; \
 	echo "       3. Upload dist/ files as release assets"; \
 	echo ""; \
 	echo "  • Documentation:"; \
 	echo "    💡 Verify installation instructions work:"; \
-	echo "       pip install kaizen-agentic==$$VERSION --extra-index-url <gitea-pypi-simple>"; \
+	echo "       pip install kaizen-agentic==$$VERSION --extra-index-url $(FORGEJO_PYPI_SIMPLE_URL)"; \
 	echo "       See docs/PACKAGE_RELEASE.md"; \
 	echo ""; \
 	echo "✅ Release finalization checklist provided"; \

README.md

@@ -1,6 +1,6 @@
 # Kaizen Agentic
 
-AI **agency** framework: 18 specialized agents that arrive in your project informed, learn from experience, and improve over time.
+AI **agency** framework: 20 specialized agents that arrive in your project informed, learn from experience, and improve 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.
 
@@ -12,7 +12,7 @@ This project embraces the Japanese concept of "kaizen" (continuous improvement)
 
 **From Source (Development):**
 ```bash
-git clone https://github.com/kaizen-agentic/kaizen-agentic.git
+git clone https://forgejo.coulomb.social/coulomb/kaizen-agentic.git
 cd kaizen-agentic
 make setup-complete
 make agents-install-cli
@@ -21,7 +21,7 @@ source .venv/bin/activate  # Required for each session
 
 **Global Installation (Available from any directory):**
 ```bash
-git clone https://github.com/kaizen-agentic/kaizen-agentic.git
+git clone https://forgejo.coulomb.social/coulomb/kaizen-agentic.git
 cd kaizen-agentic
 make setup-complete
 python3 -m build && make install-global
@@ -30,24 +30,21 @@ python3 -m build && make install-global
 
 **Local Package Testing:**
 ```bash
-git clone https://github.com/kaizen-agentic/kaizen-agentic.git
+git clone https://forgejo.coulomb.social/coulomb/kaizen-agentic.git
 cd kaizen-agentic
 make setup-complete
 python3 -m build && make install-local
 source .venv/bin/activate  # Required for each session
 ```
 
-**From Gitea PyPI (v1.1.0+):**
+**From Forgejo PyPI (current release: v1.4.0):**
 ```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/"
+  --extra-index-url https://forgejo.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/"
+  --pip-args="--extra-index-url https://forgejo.coulomb.social/api/packages/coulomb/pypi/simple/"
 ```
 
 See [docs/PACKAGE_RELEASE.md](docs/PACKAGE_RELEASE.md) for release and CI details.
@@ -92,7 +89,7 @@ kaizen-agentic memory init sys-medic
 kaizen-agentic memory brief tdd-workflow
 
 # Review an agent's accumulated knowledge
-kaizen-agentic memory show project-management
+kaizen-agentic memory show project-assistant
 ```
 
 See [docs/agency-framework.md](docs/agency-framework.md) for the full model.
@@ -108,17 +105,22 @@ Read in this order for strategic context:
 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.
+Released **v1.4.0** — see [CHANGELOG.md](CHANGELOG.md). Repository state and
+completed delivery are summarized in [SCOPE.md](SCOPE.md) and
+[WORK-RECORDS.md](WORK-RECORDS.md).
 
 Feedback: `kaizen-agentic feedback` · [docs/FEEDBACK.md](docs/FEEDBACK.md)
 
 ## Features
 
-- **20 Specialized Agents**: Project management, testing, code quality, infrastructure, meta
+- **20 Specialized Agents**: Planning, testing, code quality, infrastructure, release, and meta-agent craft
 - **Agency Framework**: Project-scoped agent memory + Coach meta-agent for cross-agent synthesis
-- **CLI Tool**: Easy agent installation, management, and memory commands (`kaizen-agentic`)
+- **Metrics and Improvement Loop**: Session evidence, optimizer recommendations, and optional artifact publication
+- **Roles and Engagements**: Versioned role packages, client-bound engagement records, lifecycle checklists, and custody controls
+- **Scheduled Preparation**: Repo-local schedules and offline orientation bundles for activity-core/Glas execution
+- **CLI Tool**: Agent, memory, metrics, protocol, engagement, and schedule commands (`kaizen-agentic`)
 - **Project Templates**: Pre-configured setups for different project types
-- **Claude Code Integration**: Seamless integration with Claude Code workflows
+- **Runtime-neutral Contracts**: Instruction and preparation surfaces usable by governed coding-agent harnesses
 - **Comprehensive Testing**: Full test coverage with multiple testing strategies
 
 ## Available Agents
@@ -127,26 +129,45 @@ Feedback: `kaizen-agentic feedback` · [docs/FEEDBACK.md](docs/FEEDBACK.md)
 - **keepaTodofile**: Manages TODO.md files following Keep a Todofile format
 - **keepaChangelog**: Maintains CHANGELOG.md files following Keep a Changelog format
 - **keepaContributingfile**: Creates and updates CONTRIBUTING.md files
-- **project-management**: General project management and coordination
+- **project-assistant**: General project planning and coordination
+- **priority-evaluation**: Evaluates and orders competing work
+- **requirements-engineering**: Requirements analysis and documentation
+- **scope-analyst**: Maintains explicit product and repository boundaries
+- **releaseManager**: Coordinates release readiness and delivery
 
 ### Development Process
 - **tdd-workflow**: Test-driven development workflow guidance
-- **requirements-engineering**: Requirements analysis and documentation
 - **test-maintenance**: Test suite maintenance and optimization
+- **testing-efficiency**: Improves test feedback speed and signal quality
 
 ### Code Quality
 - **code-refactoring**: Code improvement and refactoring guidance
 - **optimization**: Agent definition optimization and improvement
 - **datamodel-optimization**: Data model design and optimization
+- **tooling-optimization**: Improves effective use of repository tooling
 
 ### Infrastructure
 - **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
+- **wisdom-encouragement**: Encourages reflective, evidence-backed improvement
+
+## Automated execution boundary
+
+Kaizen Agentic defines agent craft, validates repo-local schedules, and prepares
+offline execution bundles. In the current unattended path, **activity-core**
+creates durable, claimable `ops_run` work. A Kaizen blueprint or agent instance
+hands a versioned `harness_profile_ref` to **glas-harness**, which resolves the
+concrete rein, model route, sandbox, tool policy, and limits and returns one
+evidence envelope. State Hub supplies roster and coordination evidence.
+
+Manual execution remains supported. Kaizen Agentic itself does not own cron,
+the durable work queue, inference, credentials, or runtime authorization. See
+[Integration Patterns](docs/INTEGRATION_PATTERNS.md) and
+[ADR-005](docs/adr/ADR-005-scheduled-agent-execution.md).
 
 [View complete agent list](docs/AGENT_DISTRIBUTION.md#agent-categories)
 

SCOPE.md

@@ -1,124 +1,217 @@
 # SCOPE
 
-> 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`.
+> This file is the operational map of the repository. For stable purpose and
+> strategic boundaries, see `INTENT.md`.
 
 ---
 
 ## One-liner
 
-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.
+KaizenAgentic is the blueprint and improvement-contract layer for versioned AI
+digital talents: agent definitions, project memory, protocols, measurement and
+optimization loops, Role/engagement reference packages, and preparation tools
+for human-led or governed automated execution.
 
 ---
 
 ## Core Idea
 
-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.
+This repository turns repeatable digital work into inspectable, versioned
+artifacts. An agent blueprint defines how a task is approached; project memory
+and protocols supply local continuity; metrics and feedback provide evidence;
+and optimization proposes the next safe refinement.
+
+KaizenAgentic **declares and prepares** agent work. It does not own the clock,
+credentials, policy enforcement, or LLM session runtime. In the current
+ecosystem, activity-core decides when/what/where and emits claimable work;
+a repo-owned instance binds a Kaizen blueprint to a versioned
+`harness_profile_ref`; glas-harness resolves the concrete execution
+constellation; and the selected rein executes a bounded session. This
+separation is the implementation of the strategic boundary in `INTENT.md`, not
+an unfinished runtime hidden in this repository.
 
 ---
 
 ## In Scope
 
-- **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
+- **Operating model and product framing**: mission, agent template,
+  meta-optimizer, guidance model, business model, pricing, and brand language
+- **Reference blueprint catalog**: 20 packaged agent definitions across project
+  management, development process, code quality, testing, infrastructure,
+  documentation, and meta-improvement
+- **Blueprint authoring and distribution**: registry, validation, generated
+  documentation, packaged-data parity, installation, migration, templates, and
+  Forgejo PyPI publication
+- **Project continuity**: `.kaizen/agents/<name>/memory.md`, Coach orientation,
+  session-start/session-close conventions, and protocol runbooks
+- **Measurement and optimization**: per-agent execution records, summaries,
+  feedback, correlation, artifact publication, event emission, and optimizer
+  recommendations
+- **Scheduling contract and preparation**: `.kaizen/schedule.yml`, validation,
+  listing, scaffolding, cadence promotion, activity-definition sync, and
+  `schedule prepare` orientation bundles
+- **Agency and engagement conventions**: loop engagements, supplier-owned Role
+  packages, staffed-role lifecycle, bound agent definitions, ramp-up/down,
+  client-custodied memory, engagement metrics, and reference pilot artifacts
+- **Interoperability contracts and reference patterns** for activity-core,
+  glas-harness, the selected reins, role-engine, agentic-resources,
+  human-resources, fin-hub, resource-control, llm-connect, State Hub,
+  artifact-store, Helix Forge, and Custodian discovery
+- **ADRs, workplans, tutorials, and integration handoffs** that make these
+  conventions human-readable and machine-consumable
 
 ---
 
 ## Out of Scope
 
-- 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)
+- Running LLM sessions or operating a multi-tenant agent runtime
+- Owning cron/event schedules, durable work queues, task lifecycle, or workflow
+  execution
+- Holding credentials or granting authentication, authorization, decision
+  rights, or tool permissions
+- Live assignment of a person or agent to an organizational role
+- Setting organizational goals, granting leadership authority, allocating the
+  agent workforce, or owning financial/resource budgets
+- Owning the complete organizational role catalog; role-engine is the current
+  definition source, while this repository may consume roles and package
+  execution-oriented reference Roles
+- Customer-specific operational state as a default; client configurations,
+  vaults, targets, and private memory belong with the client/consumer
+- Every concrete agent implementation or vendor integration; this repository
+  carries a reference fleet and portable integration patterns
+- Generic AI automation unrelated to measurable continuous improvement
+- A complete KaizenGuidance codemod platform; the guidance model remains a
+  maturity target
+- Public pypi.org distribution; the Forgejo package registry is primary
 
 ---
 
 ## Relevant When
 
-- 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
+- Defining, reviewing, packaging, or installing an agent blueprint
+- Adding project memory, Coach orientation, or reusable protocol runbooks
+- Measuring an agent run and turning evidence into a versioned improvement
+- Declaring a repo-local agent instance and preparing it for scheduled execution
+- Designing a staffed digital Role engagement or mapping an organizational role
+  to an executable agent blueprint
+- Translating leadership-owned goals and budget-constrained assignments into
+  measurable blueprint, protocol, schedule, and evidence contracts
+- Integrating Kaizen work with activity-core, glas-harness, a selected rein,
+  State Hub, Helix Forge, or artifact-store
+- Understanding the KaizenAgentic product and agency operating model
 
 ---
 
 ## Not Relevant When
 
-- 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`)
+- A task needs only ad-hoc automation with no reusable agent or improvement loop
+- The need is purely schedule/runtime operation; use activity-core,
+  glas-harness, and the selected rein
+- The need is organizational role definition only; use role-engine
+- The need is agent inventory, assignment, capacity planning, portfolio review,
+  or retirement; agentic-resources is the intended owner once its boundary is
+  ratified and implemented
+- The need is authoritative budget, burn, runway, resource capacity, or
+  procurement evidence; use fin-hub and resource-control
+- The need is identity, credentials, or authorization; use the owning identity,
+  OpenBao/credential-routing, and policy systems
+- The need is repository capability profiling or SCOPE generation at scale; use
+  repo-scoping
 
 ---
 
 ## Current State
 
-- 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)
+- **Release:** `1.4.0`, distributed through the Forgejo PyPI registry
+- **Blueprints:** 20 source and packaged definitions with parity validation
+- **CLI:** installation, registry, validation, memory, protocols, metrics,
+  feedback, agent authoring/docs, schedule, and engagement workflows
+- **Improvement loop:** metrics storage, summary, optimization, correlation,
+  publishing, and `kaizen.metrics.recorded` event emission are implemented
+- **Automation contract:** schedule manifests and offline prepare bundles are
+  implemented; activity-core has a durable `ops_run` queue; glas-harness
+  contract 1.0 resolves versioned execution profiles and is proven across two
+  rein/model constellations; rein-local intake remains where already implemented
+- **Agency model:** one supplier Role package and one staffed host-operator pilot
+  prove the file conventions; broader role-catalog integration is not yet
+  standardized
+- **Repository health:** Forgejo CI, release checks, agent validation, and
+  metadata/workplan conventions are normalized through KAIZEN-WP-0011
+- **Open maturity gap:** canonical goal/leadership/resource-envelope → role →
+  assignment → agent-instance contracts and an end-to-end role-based pilot
+  remain to be implemented
 
 ---
 
 ## How It Fits
 
-- 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)
+| Concern | Owning system | KaizenAgentic relationship |
+|---|---|---|
+| Organizational goals and leadership mandates | Accountable organization/engagement control source (`binky-control` for Binky) | Consume goal, outcome, decision-right, and escalation references; never invent strategic authority |
+| Organizational role definitions | `role-engine` | Consume stable role references and translate duties/evidence into blueprint inputs |
+| Agent workforce inventory, assignment, capacity, and portfolio review | `agentic-resources` (recommended boundary; not yet implemented) | Provide blueprint/metric contracts and receive assignment/performance references |
+| Human workforce planning and mixed-team boundaries | `human-resources` | Align compatible vocabulary without sharing human-sensitive records or treating people as compute |
+| Agent blueprints and improvement | `kaizen-agentic` | Own |
+| Repo-local agent instance | Consuming repository | Define through `.kaizen/` contracts owned jointly with runtime extensions |
+| Monetary budgets, commitments, burn, runway, and AI-plan booked cost | `fin-hub` | Consume provenance-bearing constraints; publish goal/assignment/duty attribution evidence |
+| Resource demand, capacity, allocation, utilization, and technical economics | `resource-control` | Consume capacity/cost evidence; do not duplicate resource or procurement authority |
+| Scheduling and claimable work | `activity-core` | Supply manifests, definitions, prepare commands, and event contracts |
+| Governed execution abstraction | `glas-harness` | Supply versioned `harness_profile_ref` plus blueprint/orientation and organizational references; consume normalized evidence |
+| Inner execution loop and backend policy | Glas-selected rein (`rein-aharness`, `rein-openweights`, …) | Remain rein-neutral; receive metrics and improvement evidence |
+| Model/provider abstraction | `llm-connect` | Runtime dependency outside this repository |
+| Credentials and authorization | OpenBao/credential routing, identity and policy systems | Reference named routes/profiles only; never hold grants or secrets |
+| Durable coordination evidence | Custodian State Hub | Publish/index progress and workplan state; do not own hub code |
+
+The workspace currently has `role-engine`, not a component named
+`role-manager`. Role-engine explicitly excludes live assignment and execution.
+Agentic-resources is the best-fit existing assignment/workforce owner, but its
+current implemented scope is session improvement and its root SCOPE is stale;
+that responsibility needs an explicit boundary decision before roles can be
+automated at scale.
 
 ---
 
 ## Terminology
 
-- 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; 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`
+- **Blueprint / agent definition**: versioned instructions for how an agent
+  performs a kind of work; not a running process
+- **Role definition**: organizational contract for outcomes, responsibilities,
+  authority, interfaces, escalation, and evidence; not an identity or grant
+- **Role package**: KaizenAgentic's execution-oriented reference product
+  containing blueprint/protocol/ramp assets; currently not the canonical
+  organization-wide role catalog
+- **Assignment / binding**: a record that selects who or what fills a role in a
+  specific goal/context under a leadership mandate and resource envelope;
+  agentic-resources is the recommended owner
+- **Leadership mandate**: explicit delegation of goal decomposition, decision
+  rights, review, and escalation; not implied by an agent or role name
+- **Resource envelope**: provenance-bearing financial, token, time, capacity,
+  and attention constraints delegated to an assignment
+- **Instance**: consumer-owned declaration binding a blueprint to target,
+  cadence, policy lane, tool profile, budget, memory, and metrics
+- **Engagement**: a client-scoped lifecycle and custody boundary for staffed work
+- **Harness / rein**: governed runtime that executes an instance; not owned here
+- **Agency**: the memory, coaching, measurement, and engagement operating model;
+  not unconstrained autonomous orchestration
 
 ---
 
 ## Getting Oriented
 
-Read in this order for full context:
+Read in this order:
 
-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
+1. `INTENT.md` — stable purpose and strategic boundaries
+2. `docs/assessments/2026-08-20-intent-role-automation-readiness.md` — current
+   intent fit and role-automation path
+3. `README.md` — install and daily CLI entry points
+4. `docs/agency-framework.md` — memory, Coach, protocols, metrics, and schedules
+5. `docs/adr/ADR-005-scheduled-agent-execution.md` — scheduling boundary
+6. `docs/adr/ADR-007-forward-deployed-engagement-convention.md` — staffed Roles
+7. `docs/INTEGRATION_PATTERNS.md` — ecosystem handoffs
+8. `workplans/` — implementation history and active work
 
-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`
+Key directories: `agents/`, `agents/protocols/`, `roles/`, `engagements/`,
+`src/kaizen_agentic/`, `docs/adr/`, and `wiki/`.
 
 ---
 
@@ -126,42 +219,55 @@ Entry points: `kaizen-agentic --help`; MCP: `get_kaizen_agent("scope-analyst")`;
 
 ```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]
+title: Versioned agent blueprints and protocols
+description: Twenty packaged digital-talent definitions plus reusable runbooks for guided software and operational work.
+keywords: [agents, blueprints, personas, protocols, digital-talent]
 ```
 
 ```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.
+description: Install, update, validate, author, document, and bundle agents in new or existing repositories.
 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]
+title: Project memory, coaching, and engagement lifecycle
+description: Conventions and tooling for project-scoped memory, Coach orientation, staffed Role engagements, ramp-up/down, and client-custodied evidence.
+keywords: [memory, coach, agency, engagement, roles]
 ```
 
 ```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]
+type: data
+title: Agent measurement and optimization evidence
+description: Record, summarize, correlate, publish, and emit agent performance evidence for versioned improvement decisions.
+keywords: [metrics, feedback, optimization, evidence, events]
+```
+
+```capability
+type: integration
+title: Scheduled-agent declaration and preparation
+description: Validate repo-local schedules and assemble offline orientation bundles for activity-core-triggered, harness-executed runs.
+keywords: [schedule, activity-core, glas-harness, preparation, automation]
 ```
 
 ```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]
+title: KaizenAgentic operating model and specification standards
+description: Strategic framing, design principles, agent template, optimizer model, and product/agency conventions for continuously improving digital talents.
+keywords: [kaizen, intent, template, optimization, operating-model]
 ```
 
 ---
 
 ## 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
+- `agents/` is the development source for the 20 reference definitions;
+  `src/kaizen_agentic/data/agents/` must remain synchronized with
+  `make agents-sync-package`.
+- Agent definitions still use less structure than the full
+  `wiki/KaizenAgentTemplate.md`; schema conformance is a maturity gap.
+- `.kaizen/schedule.yml` base fields are owned here. Consumer-owned agent
+  instances carry a versioned `harness_profile_ref`; Glas and the selected rein
+  validate runtime policy separately.

WORK-RECORDS.md

@@ -0,0 +1,156 @@
+# Work Records — kaizen-agentic
+
+> Generated by `statehub fix-consistency` (CUST-WP-0061-T04, work-record
+> stage 3). Do not edit by hand — edit the source file/block listed for
+> each record and re-run fix-consistency to refresh this index. Archived
+> workplans are omitted; closed decisions/intakes/engagements stay listed
+> so recently-resolved work is still visible. [auto]
+
+| Kind | ID | Status | Lane | Source |
+| --- | --- | --- | --- | --- |
+| workplan | KAIZEN-WP-ADHOC-2026-08-21 | finished | — | workplans/ADHOC-2026-08-21.md |
+| workplan | KAIZEN-WP-ADHOC-2026-09-06 | finished | — | workplans/ADHOC-2026-09-06.md |
+| workplan | KAIZEN-WP-0001 | finished | — | workplans/KAIZEN-WP-0001-community-engagement.md |
+| workplan | KAIZEN-WP-0002 | finished | — | workplans/KAIZEN-WP-0002-agency-framework.md |
+| workplan | KAIZEN-WP-0003 | finished | — | workplans/KAIZEN-WP-0003-measurement-loop.md |
+| workplan | KAIZEN-WP-0004 | finished | — | workplans/KAIZEN-WP-0004-ecosystem-integration.md |
+| workplan | KAIZEN-WP-0005 | finished | — | workplans/KAIZEN-WP-0005-adoption-parity.md |
+| workplan | KAIZEN-WP-0006 | finished | — | workplans/KAIZEN-WP-0006-scheduled-agent-execution.md |
+| workplan | KAIZEN-WP-0007 | finished | — | workplans/KAIZEN-WP-0007-agent-authoring-doc-generation.md |
+| workplan | KAIZEN-WP-0008 | finished | — | workplans/KAIZEN-WP-0008-coulomb-loop-supplier-engagement.md |
+| workplan | KAIZEN-WP-0009 | finished | — | workplans/KAIZEN-WP-0009-forward-deployed-agency.md |
+| workplan | KAIZEN-WP-0010 | finished | — | workplans/KAIZEN-WP-0010-forgejo-pypi-migration.md |
+| workplan | KAIZEN-WP-0011 | finished | — | workplans/KAIZEN-WP-0011-repository-health-normalization.md |
+| workplan | KAIZEN-WP-0012 | finished | — | workplans/KAIZEN-WP-0012-scope-intent-role-automation-assessment.md |
+| workplan | KAIZEN-WP-0013 | finished | — | workplans/KAIZEN-WP-0013-agent-workforce-goal-budget-governance.md |
+| workplan | KAIZEN-WP-0014 | finished | — | workplans/KAIZEN-WP-0014-repository-consolidation.md |
+| task | KAIZEN-WP-ADHOC-2026-08-21-T01 | done | — | workplans/ADHOC-2026-08-21.md |
+| task | KAIZEN-WP-ADHOC-2026-09-06-T01 | done | — | workplans/ADHOC-2026-09-06.md |
+| task | T01 | done | — | workplans/KAIZEN-WP-0003-measurement-loop.md |
+| task | T02 | done | — | workplans/KAIZEN-WP-0003-measurement-loop.md |
+| task | T03 | done | — | workplans/KAIZEN-WP-0003-measurement-loop.md |
+| task | T04 | done | — | workplans/KAIZEN-WP-0003-measurement-loop.md |
+| task | T05 | done | — | workplans/KAIZEN-WP-0003-measurement-loop.md |
+| task | T06 | done | — | workplans/KAIZEN-WP-0003-measurement-loop.md |
+| task | T07 | done | — | workplans/KAIZEN-WP-0003-measurement-loop.md |
+| task | T08 | done | — | workplans/KAIZEN-WP-0003-measurement-loop.md |
+| task | T09 | done | — | workplans/KAIZEN-WP-0003-measurement-loop.md |
+| task | T10 | done | — | workplans/KAIZEN-WP-0003-measurement-loop.md |
+| task | T11 | done | — | workplans/KAIZEN-WP-0003-measurement-loop.md |
+| task | T12 | done | — | workplans/KAIZEN-WP-0003-measurement-loop.md |
+| task | T13 | done | — | workplans/KAIZEN-WP-0003-measurement-loop.md |
+| task | T14 | done | — | workplans/KAIZEN-WP-0003-measurement-loop.md |
+| task | T15 | done | — | workplans/KAIZEN-WP-0003-measurement-loop.md |
+| task | T16 | done | — | workplans/KAIZEN-WP-0003-measurement-loop.md |
+| task | T17 | done | — | workplans/KAIZEN-WP-0003-measurement-loop.md |
+| task | T18 | done | — | workplans/KAIZEN-WP-0003-measurement-loop.md |
+| task | T19 | done | — | workplans/KAIZEN-WP-0003-measurement-loop.md |
+| task | T20 | done | — | workplans/KAIZEN-WP-0003-measurement-loop.md |
+| task | T21 | done | — | workplans/KAIZEN-WP-0003-measurement-loop.md |
+| task | T22 | done | — | workplans/KAIZEN-WP-0003-measurement-loop.md |
+| task | T23 | done | — | workplans/KAIZEN-WP-0003-measurement-loop.md |
+| task | T24 | done | — | workplans/KAIZEN-WP-0003-measurement-loop.md |
+| task | T01 | done | — | workplans/KAIZEN-WP-0004-ecosystem-integration.md |
+| task | T02 | done | — | workplans/KAIZEN-WP-0004-ecosystem-integration.md |
+| task | T03 | done | — | workplans/KAIZEN-WP-0004-ecosystem-integration.md |
+| task | T04 | done | — | workplans/KAIZEN-WP-0004-ecosystem-integration.md |
+| task | T05 | done | — | workplans/KAIZEN-WP-0004-ecosystem-integration.md |
+| task | T06 | done | — | workplans/KAIZEN-WP-0004-ecosystem-integration.md |
+| task | T07 | done | — | workplans/KAIZEN-WP-0004-ecosystem-integration.md |
+| task | T08 | done | — | workplans/KAIZEN-WP-0004-ecosystem-integration.md |
+| task | T09 | done | — | workplans/KAIZEN-WP-0004-ecosystem-integration.md |
+| task | T10 | done | — | workplans/KAIZEN-WP-0004-ecosystem-integration.md |
+| task | T11 | done | — | workplans/KAIZEN-WP-0004-ecosystem-integration.md |
+| task | T12 | done | — | workplans/KAIZEN-WP-0004-ecosystem-integration.md |
+| task | T13 | done | — | workplans/KAIZEN-WP-0004-ecosystem-integration.md |
+| task | T14 | done | — | workplans/KAIZEN-WP-0004-ecosystem-integration.md |
+| task | T15 | done | — | workplans/KAIZEN-WP-0004-ecosystem-integration.md |
+| task | T16 | done | — | workplans/KAIZEN-WP-0004-ecosystem-integration.md |
+| task | T17 | done | — | workplans/KAIZEN-WP-0004-ecosystem-integration.md |
+| task | T18 | done | — | workplans/KAIZEN-WP-0004-ecosystem-integration.md |
+| task | T19 | done | — | workplans/KAIZEN-WP-0004-ecosystem-integration.md |
+| task | T01 | done | — | workplans/KAIZEN-WP-0005-adoption-parity.md |
+| task | T02 | done | — | workplans/KAIZEN-WP-0005-adoption-parity.md |
+| task | T03 | done | — | workplans/KAIZEN-WP-0005-adoption-parity.md |
+| task | T04 | done | — | workplans/KAIZEN-WP-0005-adoption-parity.md |
+| task | T05 | done | — | workplans/KAIZEN-WP-0005-adoption-parity.md |
+| task | T06 | done | — | workplans/KAIZEN-WP-0005-adoption-parity.md |
+| task | T07 | done | — | workplans/KAIZEN-WP-0005-adoption-parity.md |
+| task | T08 | done | — | workplans/KAIZEN-WP-0005-adoption-parity.md |
+| task | T09 | done | — | workplans/KAIZEN-WP-0005-adoption-parity.md |
+| task | T10 | done | — | workplans/KAIZEN-WP-0005-adoption-parity.md |
+| task | T11 | done | — | workplans/KAIZEN-WP-0005-adoption-parity.md |
+| task | T12 | done | — | workplans/KAIZEN-WP-0005-adoption-parity.md |
+| task | T13 | done | — | workplans/KAIZEN-WP-0005-adoption-parity.md |
+| task | T14 | done | — | workplans/KAIZEN-WP-0005-adoption-parity.md |
+| task | T15 | done | — | workplans/KAIZEN-WP-0005-adoption-parity.md |
+| task | T16 | done | — | workplans/KAIZEN-WP-0005-adoption-parity.md |
+| task | T01 | done | — | workplans/KAIZEN-WP-0006-scheduled-agent-execution.md |
+| task | T02 | done | — | workplans/KAIZEN-WP-0006-scheduled-agent-execution.md |
+| task | T03 | done | — | workplans/KAIZEN-WP-0006-scheduled-agent-execution.md |
+| task | T04 | done | — | workplans/KAIZEN-WP-0006-scheduled-agent-execution.md |
+| task | T05 | done | — | workplans/KAIZEN-WP-0006-scheduled-agent-execution.md |
+| task | T06 | done | — | workplans/KAIZEN-WP-0006-scheduled-agent-execution.md |
+| task | T07 | done | — | workplans/KAIZEN-WP-0006-scheduled-agent-execution.md |
+| task | T08 | done | — | workplans/KAIZEN-WP-0006-scheduled-agent-execution.md |
+| task | T09 | done | — | workplans/KAIZEN-WP-0006-scheduled-agent-execution.md |
+| task | T10 | done | — | workplans/KAIZEN-WP-0006-scheduled-agent-execution.md |
+| task | T11 | done | — | workplans/KAIZEN-WP-0006-scheduled-agent-execution.md |
+| task | T12 | done | — | workplans/KAIZEN-WP-0006-scheduled-agent-execution.md |
+| task | T13 | done | — | workplans/KAIZEN-WP-0006-scheduled-agent-execution.md |
+| task | T14 | done | — | workplans/KAIZEN-WP-0006-scheduled-agent-execution.md |
+| task | T15 | done | — | workplans/KAIZEN-WP-0006-scheduled-agent-execution.md |
+| task | T16 | done | — | workplans/KAIZEN-WP-0006-scheduled-agent-execution.md |
+| task | T17 | done | — | workplans/KAIZEN-WP-0006-scheduled-agent-execution.md |
+| task | T18 | done | — | workplans/KAIZEN-WP-0006-scheduled-agent-execution.md |
+| task | T01 | done | — | workplans/KAIZEN-WP-0007-agent-authoring-doc-generation.md |
+| task | T02 | done | — | workplans/KAIZEN-WP-0007-agent-authoring-doc-generation.md |
+| task | T03 | done | — | workplans/KAIZEN-WP-0007-agent-authoring-doc-generation.md |
+| task | T04 | done | — | workplans/KAIZEN-WP-0007-agent-authoring-doc-generation.md |
+| task | T05 | done | — | workplans/KAIZEN-WP-0007-agent-authoring-doc-generation.md |
+| task | T06 | done | — | workplans/KAIZEN-WP-0007-agent-authoring-doc-generation.md |
+| task | KAIZEN-WP-0008-T01 | done | — | workplans/KAIZEN-WP-0008-coulomb-loop-supplier-engagement.md |
+| task | KAIZEN-WP-0008-T02 | done | — | workplans/KAIZEN-WP-0008-coulomb-loop-supplier-engagement.md |
+| task | KAIZEN-WP-0008-T03 | done | — | workplans/KAIZEN-WP-0008-coulomb-loop-supplier-engagement.md |
+| task | KAIZEN-WP-0008-T04 | done | — | workplans/KAIZEN-WP-0008-coulomb-loop-supplier-engagement.md |
+| task | KAIZEN-WP-0008-T05 | done | — | workplans/KAIZEN-WP-0008-coulomb-loop-supplier-engagement.md |
+| task | KAIZEN-WP-0008-T06 | done | — | workplans/KAIZEN-WP-0008-coulomb-loop-supplier-engagement.md |
+| task | KAIZEN-WP-0008-T07 | done | — | workplans/KAIZEN-WP-0008-coulomb-loop-supplier-engagement.md |
+| task | KAIZEN-WP-0008-T08 | done | — | workplans/KAIZEN-WP-0008-coulomb-loop-supplier-engagement.md |
+| task | KAIZEN-WP-0008-T09 | done | — | workplans/KAIZEN-WP-0008-coulomb-loop-supplier-engagement.md |
+| task | KAIZEN-WP-0008-T10 | done | — | workplans/KAIZEN-WP-0008-coulomb-loop-supplier-engagement.md |
+| task | KAIZEN-WP-0009-T01 | done | — | workplans/KAIZEN-WP-0009-forward-deployed-agency.md |
+| task | KAIZEN-WP-0009-T02 | done | — | workplans/KAIZEN-WP-0009-forward-deployed-agency.md |
+| task | KAIZEN-WP-0009-T03 | done | — | workplans/KAIZEN-WP-0009-forward-deployed-agency.md |
+| task | KAIZEN-WP-0009-T04 | done | — | workplans/KAIZEN-WP-0009-forward-deployed-agency.md |
+| task | KAIZEN-WP-0009-T05 | done | — | workplans/KAIZEN-WP-0009-forward-deployed-agency.md |
+| task | KAIZEN-WP-0009-T06 | done | — | workplans/KAIZEN-WP-0009-forward-deployed-agency.md |
+| task | KAIZEN-WP-0009-T07 | done | — | workplans/KAIZEN-WP-0009-forward-deployed-agency.md |
+| task | KAIZEN-WP-0009-T08 | done | — | workplans/KAIZEN-WP-0009-forward-deployed-agency.md |
+| task | KAIZEN-WP-0009-T09 | done | — | workplans/KAIZEN-WP-0009-forward-deployed-agency.md |
+| task | KAIZEN-WP-0009-T10 | done | — | workplans/KAIZEN-WP-0009-forward-deployed-agency.md |
+| task | KAIZEN-WP-0009-T11 | done | — | workplans/KAIZEN-WP-0009-forward-deployed-agency.md |
+| task | KAIZEN-WP-0010-T01 | done | — | workplans/KAIZEN-WP-0010-forgejo-pypi-migration.md |
+| task | KAIZEN-WP-0010-T02 | done | — | workplans/KAIZEN-WP-0010-forgejo-pypi-migration.md |
+| task | KAIZEN-WP-0010-T03 | done | — | workplans/KAIZEN-WP-0010-forgejo-pypi-migration.md |
+| task | KAIZEN-WP-0010-T04 | done | — | workplans/KAIZEN-WP-0010-forgejo-pypi-migration.md |
+| task | KAIZEN-WP-0010-T05 | done | — | workplans/KAIZEN-WP-0010-forgejo-pypi-migration.md |
+| task | KAIZEN-WP-0011-T01 | done | — | workplans/KAIZEN-WP-0011-repository-health-normalization.md |
+| task | KAIZEN-WP-0011-T02 | done | — | workplans/KAIZEN-WP-0011-repository-health-normalization.md |
+| task | KAIZEN-WP-0011-T03 | done | — | workplans/KAIZEN-WP-0011-repository-health-normalization.md |
+| task | KAIZEN-WP-0011-T04 | done | — | workplans/KAIZEN-WP-0011-repository-health-normalization.md |
+| task | KAIZEN-WP-0011-T05 | done | — | workplans/KAIZEN-WP-0011-repository-health-normalization.md |
+| task | KAIZEN-WP-0012-T01 | done | — | workplans/KAIZEN-WP-0012-scope-intent-role-automation-assessment.md |
+| task | KAIZEN-WP-0012-T02 | done | — | workplans/KAIZEN-WP-0012-scope-intent-role-automation-assessment.md |
+| task | KAIZEN-WP-0012-T03 | done | — | workplans/KAIZEN-WP-0012-scope-intent-role-automation-assessment.md |
+| task | KAIZEN-WP-0012-T04 | done | — | workplans/KAIZEN-WP-0012-scope-intent-role-automation-assessment.md |
+| task | KAIZEN-WP-0013-T01 | done | — | workplans/KAIZEN-WP-0013-agent-workforce-goal-budget-governance.md |
+| task | KAIZEN-WP-0013-T02 | done | — | workplans/KAIZEN-WP-0013-agent-workforce-goal-budget-governance.md |
+| task | KAIZEN-WP-0013-T03 | done | — | workplans/KAIZEN-WP-0013-agent-workforce-goal-budget-governance.md |
+| task | KAIZEN-WP-0013-T04 | done | — | workplans/KAIZEN-WP-0013-agent-workforce-goal-budget-governance.md |
+| task | KAIZEN-WP-0014-T01 | done | — | workplans/KAIZEN-WP-0014-repository-consolidation.md |
+| task | KAIZEN-WP-0014-T02 | done | — | workplans/KAIZEN-WP-0014-repository-consolidation.md |
+| task | KAIZEN-WP-0014-T03 | done | — | workplans/KAIZEN-WP-0014-repository-consolidation.md |
+| task | KAIZEN-WP-0014-T04 | done | — | workplans/KAIZEN-WP-0014-repository-consolidation.md |
+| task | KAIZEN-WP-0014-T05 | done | — | workplans/KAIZEN-WP-0014-repository-consolidation.md |
+| task | KAIZEN-WP-0014-T06 | done | — | workplans/KAIZEN-WP-0014-repository-consolidation.md |

agents/agent-keepaContributingfile.md

@@ -18,7 +18,7 @@ You are the Contributing Keeper, a specialized agent focused on maintaining CONT
 2. **Welcoming Onboarding**: Provide friendly, accessible instructions that lower the barrier to entry for new contributors
 3. **Quality Standards**: Set clear expectations for code style, testing, and documentation aligned with PythonVibes standards
 4. **Workflow Documentation**: Define contribution types, development setup, and submission processes
-5. **Agent Integration**: Seamlessly integrate the 17+ specialized agents and Kaizen philosophy into contribution workflows
+5. **Agent Integration**: Seamlessly integrate the 20 specialized agents and Kaizen philosophy into contribution workflows
 6. **Community Building**: Foster a professional tone and maintain behavioral expectations
 
 ### Authority and Scope
@@ -30,7 +30,7 @@ You have explicit authority to:
 - Establish welcoming, friendly tone that encourages participation rather than intimidating newcomers
 - Define clear development setup instructions with proper virtual environment and dependency management
 - Create issue reporting guidelines and pull request submission workflows
-- Integrate the 17+ specialized agents naturally into contribution processes
+- Integrate the 20 specialized agents naturally into contribution processes
 - Reference the comprehensive Makefile commands and testing infrastructure
 - Maintain focus on reducing maintainer burden while improving contribution quality
 - Avoid antipatterns: outdated information, overly demanding processes, unwelcoming tone, lack of templates
@@ -161,7 +161,7 @@ When reporting bugs, please include:
 
 ## Agent-Assisted Development
 
-This repository includes 17+ specialized agents to assist with development:
+This repository includes 20 specialized agents to assist with development:
 - Use `todo-keeper` for TODO.md maintenance
 - Use `changelog-keeper` for CHANGELOG.md updates
 - Use `contributing-keeper` for this file maintenance

agents/agent-project-assistant.md

@@ -21,12 +21,12 @@ You are the MarkiTect project assistant, specialized in providing project status
 - **roadmap/**: Directory with current and close range roadmap-topic-directories for concepts, workplans, examples...
 - **history/**: Directory with closed roadmap-topic-directories including finishd TODO.md files as YYMMDD-DONE.md
 - **Makefile**: Provides helpers to use and improve the capabilities provided by the project
-  **Gitea Issues**: Backlog of issues and backlog of tasks stored as issues in gitea before selection as roadmap topics
+  **Forgejo Issues**: Backlog of issues and tasks stored as issues in Forgejo before selection as roadmap topics
 
 ### Project Infrastructure Knowledge
 
 **Repository Structure:**
-- Main project hosted on Gitea with issue tracking for use cases and tasks
+- Main project hosted on Forgejo 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/
@@ -36,7 +36,7 @@ You are the MarkiTect project assistant, specialized in providing project status
 Important: Respect the directory structure! If in doubt ask or use directories under tmp/ to keep the structure clean!
 
 **Development Workflow:**
-- Issue-driven development using Gitea API integration
+- Issue-driven development using Forgejo API integration
 - Issue management via universal issue-facade CLI that works with multiple backends
 - All commits require green test state
 
@@ -48,8 +48,8 @@ Important: Respect the directory structure! If in doubt ask or use directories u
 - **Discovery Tools**: `make capability-search TERM=xyz` to find existing functionality
 
 **Issue Management Protocol:**
-- **Gitea-First**: Feature requests, bugs, and enhancements should be documented as Gitea issues
-- **Issue Creation**: When new requirements emerge, create issues in Gitea immediately but do NOT implement immediately
+- **Forgejo-First**: Feature requests, bugs, and enhancements should be documented as Forgejo issues
+- **Issue Creation**: When new requirements emerge, create issues in Forgejo immediately but do NOT implement immediately
 - **Strategic Planning**: Issues should be prioritized and scheduled based on project roadmap (history/ROADMAP.md)
 - **Implementation Discipline**: Only work on issues that are explicitly planned for the current session
 - **Issue Workflow**: Create → Triage → Plan → Schedule → Implement → Close
@@ -67,12 +67,12 @@ When asked about project status or next steps:
 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
-5. **Planning New Stuff**: Requirements (Epics and Stories) are gitea issues to be planned as roadmap topics
+5. **Planning New Stuff**: Requirements (Epics and Stories) are Forgejo issues to be planned as roadmap topics
 6. **Consider Git Status**: Allways be aware of current working directory state and recent commits
 
 ### Issue Management Guidelines
 
-**When to Create Gitea Issues:**
+**When to Create Forgejo Issues:**
 - New feature requests or enhancement ideas emerge during development
 - Bugs or technical debt are discovered but not immediately fixable
 - Future improvements are identified but outside current session and topic scope

agents/agent-releaseManager.md

@@ -21,7 +21,7 @@ You are a specialized release management agent focused on Python package publica
 - **Package Building**: Build distribution packages (sdist and wheel) using modern Python tools
 - **Quality Assurance**: Run comprehensive tests and validation before publication
 - **PyPI Publication**: Handle TestPyPI and production PyPI uploads with proper authentication
-- **Post-Release Tasks**: Update documentation, create GitHub releases, and notify stakeholders
+- **Post-Release Tasks**: Update documentation, create Forgejo releases, and notify stakeholders
 
 ### Documentation Updates
 - **Installation Instructions**: Update installation guides to reflect publication status
@@ -39,7 +39,7 @@ You are a specialized release management agent focused on Python package publica
 ### Production Release
 - Full validation and testing required
 - Publish to production PyPI
-- Create GitHub releases with assets
+- Create Forgejo releases with assets
 - Update all documentation
 
 ### Patch Releases
@@ -55,7 +55,7 @@ Provide these release- prefixed make targets:
 - `release-prepare`: Prepare release (update versions, build packages)
 - `release-test`: Test publication workflow using TestPyPI
 - `release-publish`: Publish to production PyPI
-- `release-finalize`: Post-release tasks (tags, GitHub release, documentation)
+- `release-finalize`: Post-release tasks (tags, Forgejo release, documentation)
 - `release-rollback`: Emergency rollback procedures
 
 ## Best Practices
@@ -83,7 +83,7 @@ Provide these release- prefixed make targets:
 ## Integration Points
 
 ### CI/CD Systems
-- GitHub Actions workflow integration
+- Forgejo Actions workflow integration
 - Automated testing on multiple Python versions
 - Security scanning and dependency checking
 - Automated documentation deployment

agents/agent-tdd-workflow.md

@@ -123,7 +123,7 @@ You are the authoritative guide for the TDD8 workflow using the tddai system. Yo
 **Supporting Commands:**
 - `make test-coverage NUM=X` - Analyze test coverage for an issue
 - `make test` - Run all tests
-- `make list-issues` - Show all Gitea issues with status
+- `make list-issues` - Show all Forgejo issues with status
 - `make show-issue NUM=X` - Show detailed view of specific issue
 
 ### Workspace Management Understanding
@@ -306,7 +306,7 @@ Extend data access layer with search methods. Consider adding full-text search f
 - **Issue Tracker Integration:** Compatible with Gitea, GitHub, and similar platforms
 - **Issue Reading:** Use `IssueFetcher` for programmatic access
 - **Issue Writing:** Use `IssueWriter` for updates via authenticated PATCH
-- **Environment Variables:** `GITEA_API_TOKEN` or platform-specific tokens for authentication
+- **Environment Variables:** `FORGEJO_API_TOKEN` or platform-specific tokens for authentication
 
 ### Test Framework
 - **pytest-based:** All tests use pytest framework

agents/agent-test-maintenance.md

@@ -86,7 +86,7 @@ Remove tests when:
 - Update tests to reflect new command structures and access patterns
 
 ### Backend Systems
-- **Primary**: Gitea backend for issue management
+- **Primary**: Forgejo backend for issue management
 - **Secondary**: Local plugin for offline/alternative workflows
 - **Focus**: Prioritize tests for actively used functionality
 
@@ -122,7 +122,7 @@ ACTION: Modify assertions to match new CLI structure
 ### Scenario 2: Obsolete Functionality
 ```
 FAILING: test_local_plugin_sequential_numbering()
-CAUSE: Local plugin not actively used, Gitea is primary backend
+CAUSE: Local plugin not actively used, Forgejo is primary backend
 DECISION: Remove test as functionality is not essential to current workflow
 ACTION: Remove test method and document rationale
 ```

docs/AGENT_DISTRIBUTION.md

@@ -13,14 +13,11 @@ The Kaizen Agentic framework provides a comprehensive system for distributing an
 
 ## Installation
 
-Install the Kaizen Agentic package from the Coulomb Gitea PyPI registry:
+Install the Kaizen Agentic package from the Forgejo PyPI registry:
 
 ```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/"
+  --extra-index-url https://forgejo.coulomb.social/api/packages/coulomb/pypi/simple/
 ```
 
 This provides the `kaizen-agentic` CLI tool for managing agents. See

docs/CLI_CHEAT_SHEET.md

@@ -4,14 +4,11 @@ Quick reference for the `kaizen-agentic` command-line tool.
 
 ## Installation
 
-From Coulomb Gitea PyPI (see [PACKAGE_RELEASE.md](PACKAGE_RELEASE.md)):
+From Forgejo PyPI (see [PACKAGE_RELEASE.md](PACKAGE_RELEASE.md)):
 
 ```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/"
+  --extra-index-url https://forgejo.coulomb.social/api/packages/coulomb/pypi/simple/
 ```
 
 ## Core Commands
@@ -122,8 +119,12 @@ 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.
+activity-core fires the schedule and creates durable `ops_run` work per
+(repo, agent). Rein-local intake or another caller receives that work and runs
+`schedule prepare`; the blueprint/instance then hands an explicit versioned
+`harness_profile_ref` to Glas for rein/model/sandbox/tool resolution.
+kaizen-agentic does not run cron, own the queue, resolve credentials, select a
+concrete rein, or invoke an LLM.
 
 ### Forward-deployed engagements (WP-0009 / DEC-FDA-001)
 ```bash

docs/FEEDBACK.md

@@ -6,12 +6,12 @@ How to share bugs, ideas, and adoption experience for kaizen-agentic.
 
 | Channel | Use for |
 |---------|---------|
-| **Gitea Issues** | Bugs, features, general feedback (templates below) |
+| **Forgejo 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
+## Forgejo issue templates
 
 Choose a template when opening a new issue:
 
@@ -19,7 +19,7 @@ Choose a template when opening a new issue:
 - **Feature request** — enhancements with proposed scope
 - **General feedback** — experience and adoption notes
 
-Repository: [coulomb/kaizen-agentic](https://gitea.coulomb.social/coulomb/kaizen-agentic/issues)
+Repository: [coulomb/kaizen-agentic](https://forgejo.coulomb.social/coulomb/kaizen-agentic/issues)
 
 ## CLI
 

docs/GETTING_STARTED.md

@@ -12,7 +12,7 @@ This guide walks you through using Kaizen Agentic agents in any project, from in
 
 ```bash
 # Clone the repository
-git clone https://github.com/kaizen-agentic/kaizen-agentic.git
+git clone https://forgejo.coulomb.social/coulomb/kaizen-agentic.git
 cd kaizen-agentic
 
 # Set up development environment
@@ -29,7 +29,7 @@ source .venv/bin/activate
 
 ```bash
 # Clone the repository and build package
-git clone https://github.com/kaizen-agentic/kaizen-agentic.git
+git clone https://forgejo.coulomb.social/coulomb/kaizen-agentic.git
 cd kaizen-agentic
 make setup-complete
 
@@ -45,7 +45,7 @@ source .venv/bin/activate
 
 ```bash
 # Clone the repository and build package
-git clone https://github.com/kaizen-agentic/kaizen-agentic.git
+git clone https://forgejo.coulomb.social/coulomb/kaizen-agentic.git
 cd kaizen-agentic
 make setup-complete
 
@@ -57,21 +57,18 @@ make install-global
 # CLI available from any directory
 ```
 
-**Option D: From Gitea PyPI (v1.1.0+)**
+**Option D: From Forgejo PyPI (v1.1.0+)**
 
 ```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/"
+  --extra-index-url https://forgejo.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/"
+  --pip-args="--extra-index-url https://forgejo.coulomb.social/api/packages/coulomb/pypi/simple/"
 ```
 
-> **📦 Registry**: Published on the Coulomb Gitea PyPI registry. Dependencies resolve
+> **📦 Registry**: Published on the Forgejo PyPI registry. Dependencies resolve
 > from public PyPI via `--extra-index-url`. See [PACKAGE_RELEASE.md](PACKAGE_RELEASE.md).
 
 ### 2. Verify Installation
@@ -273,7 +270,7 @@ jobs:
           python-version: '3.8'
       - 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/"
+          --extra-index-url https://forgejo.coulomb.social/api/packages/coulomb/pypi/simple/
       - run: kaizen-agentic validate
 ```
 
@@ -413,7 +410,7 @@ kaizen-agentic status
 # New team member setup
 git clone project-repo
 cd project-repo
-# see Option D for GITEA_PACKAGE_USER / GITEA_PACKAGE_TOKEN and --extra-index-url
+# see Option D for the Forgejo --extra-index-url
 pip install kaizen-agentic
 kaizen-agentic status       # See what agents are used
 kaizen-agentic validate     # Verify everything works
@@ -428,16 +425,14 @@ cat CLAUDE.md
 
 **"Command not found: kaizen-agentic"**
 ```bash
-# Install from Gitea PyPI (same credentials as Option D)
-export GITEA_PACKAGE_USER=<gitea-user>
-export GITEA_PACKAGE_TOKEN=<package-token>
+# Install from Forgejo PyPI (same endpoint as Option D)
 pip install kaizen-agentic \
-  --extra-index-url "https://${GITEA_PACKAGE_USER}:${GITEA_PACKAGE_TOKEN}@gitea.coulomb.social/api/packages/coulomb/pypi/simple/"
+  --extra-index-url https://forgejo.coulomb.social/api/packages/coulomb/pypi/simple/
 
 # Or if using virtual env:
 source .venv/bin/activate
 pip install kaizen-agentic \
-  --extra-index-url "https://${GITEA_PACKAGE_USER}:${GITEA_PACKAGE_TOKEN}@gitea.coulomb.social/api/packages/coulomb/pypi/simple/"
+  --extra-index-url https://forgejo.coulomb.social/api/packages/coulomb/pypi/simple/
 ```
 
 **"No agents directory found"**

docs/HELLO_WORLD_TUTORIAL.md

@@ -9,14 +9,11 @@ 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):
+From the Forgejo PyPI registry (dependencies resolve from public PyPI):
 
 ```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/"
+  --extra-index-url https://forgejo.coulomb.social/api/packages/coulomb/pypi/simple/
 ```
 
 See [PACKAGE_RELEASE.md](PACKAGE_RELEASE.md) for pipx and release details.
@@ -243,11 +240,9 @@ kaizen-agentic status
 
 **"kaizen-agentic: command not found"**
 ```bash
-# Same install as Step 1 (Gitea extra index — see PACKAGE_RELEASE.md)
-export GITEA_PACKAGE_USER=<gitea-user>
-export GITEA_PACKAGE_TOKEN=<package-token>
+# Same install as Step 1 (Forgejo extra index — see PACKAGE_RELEASE.md)
 pip install kaizen-agentic \
-  --extra-index-url "https://${GITEA_PACKAGE_USER}:${GITEA_PACKAGE_TOKEN}@gitea.coulomb.social/api/packages/coulomb/pypi/simple/"
+  --extra-index-url https://forgejo.coulomb.social/api/packages/coulomb/pypi/simple/
 ```
 
 **"make: command not found"**

docs/INTEGRATION_PATTERNS.md

@@ -4,7 +4,7 @@ How kaizen-agentic composes with ecosystem repos **by contract** — no merged
 codebases, no duplicated capabilities.
 
 Reference: [wiki/EcosystemIntegration.md](../wiki/EcosystemIntegration.md),
-[KAIZEN-WP-0004](../workplans/kaizen-agentic-WP-0004-ecosystem-integration.md).
+[KAIZEN-WP-0004](../workplans/KAIZEN-WP-0004-ecosystem-integration.md).
 
 ---
 
@@ -52,13 +52,13 @@ invoke kaizen-agentic CLI commands.
 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).
+   Forgejo 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
+- [x] Three definition files committed under `docs/integrations/activity-definitions/`
+- [x] activity-core handoff completed for the resolver and pilot definitions
+- [x] Smoke test commands documented below passed on the pilot roster
 
 **Smoke test (manual):**
 
@@ -71,7 +71,7 @@ kaizen-agentic metrics optimize
 test -f .kaizen/metrics/optimizer/analysis.json && echo OK
 ```
 
-**Boundary:** kaizen-agentic does not run Temporal schedules.
+**Boundary:** kaizen-agentic does not run Temporal schedules or own durable work.
 
 ### Scheduled agent execution (WP-0006, ADR-005)
 
@@ -109,8 +109,29 @@ kaizen-agentic schedule validate && kaizen-agentic schedule list
 - [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
 
-**Boundary:** kaizen-agentic declares and prepares; activity-core schedules;
-state-hub owns the roster.
+### Current automated runtime
+
+The original WP-0006 resolver and manual prepare smoke established the supplier
+contract. Current unattended execution composes it as follows:
+
+| Stage | Owner | Contract |
+|-------|-------|----------|
+| Schedule/event and eligibility | activity-core | Temporal definition/rule plus repo/agent context |
+| Durable work | activity-core | Unique idempotency key, `ops_run` state, lease, retry, result |
+| Task intake | Caller or selected rein | Claim/receive bounded work; intake remains rein-local where implemented |
+| Agent orientation | kaizen-agentic | `schedule prepare <agent>` offline bundle |
+| Execution resolution | glas-harness | Explicit versioned `harness_profile_ref` → rein/model/sandbox/tools/limits; normalized evidence |
+| Inner execution | Glas-selected rein | Backend-specific bounded loop, policy enforcement, and credential use |
+| Coordination evidence | State Hub | Roster, workplan/progress references; never prompts or secrets |
+| Improvement evidence | kaizen-agentic / artifact-store | Project metrics and optional durable artifacts |
+
+Manual invocation remains supported for smoke tests and operator-controlled
+work. The automated path should keep prompts, secrets, and raw model output out
+of `ops_run` and State Hub records.
+
+**Boundary:** kaizen-agentic declares and prepares; activity-core schedules and
+queues; glas-harness resolves the explicit execution profile; the selected rein
+executes; State Hub owns the roster and coordination view.
 
 ---
 

docs/PACKAGE_RELEASE.md

@@ -1,30 +1,27 @@
 # 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
+`kaizen-agentic` publishes as the `kaizen-agentic` Python package on the Forgejo
+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:
+Dependencies such as `pyyaml` resolve from public PyPI. Use Forgejo 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/"
+  --extra-index-url https://forgejo.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/"
+  --pip-args="--extra-index-url https://forgejo.coulomb.social/api/packages/coulomb/pypi/simple/"
 ```
 
-Do not commit tokenized index URLs. Inject credentials via environment variables or
-CI secrets.
+Consumer reads are anonymous. Keep publish credentials in Forgejo Actions secrets
+or inject them through the environment for a deliberate local release.
 
 ## Local Release
 
@@ -37,53 +34,47 @@ make package-check
 Publish to the Coulomb organization registry:
 
 ```bash
-TWINE_USERNAME=<gitea-user> \
+TWINE_USERNAME=<forgejo-user> \
 TWINE_PASSWORD=<package-token> \
-make publish-gitea
+make publish-forgejo
 ```
 
 Package upload endpoint:
 
 ```text
-https://gitea.coulomb.social/api/packages/coulomb/pypi
+https://forgejo.coulomb.social/api/packages/coulomb/pypi
 ```
 
 Consumer simple index:
 
 ```text
-https://gitea.coulomb.social/api/packages/coulomb/pypi/simple/
+https://forgejo.coulomb.social/api/packages/coulomb/pypi/simple/
 ```
 
-## Gitea repository secrets (one-time)
+## Forgejo repository secrets (one-time)
 
-Configure in Gitea: **Repository → Settings → Actions → Secrets**.
+Configure in Forgejo: **Repository → Settings → Actions → Secrets** (or use
+organization-level secrets when managed centrally).
 
 | Secret | Value |
 |--------|-------|
-| `PACKAGE_USER` | `tegwick` — Gitea username that owns the package token |
-| `PACKAGE_TOKEN` | Gitea API token named `inter-hub-pkg-rep` (`write:package`) |
+| `FORGEJO_PYPI_USER` | Forgejo username that owns the package token |
+| `FORGEJO_PYPI_TOKEN` | Forgejo token with package-write permission |
 
-Token custody (OpenBao):
+Discover credential ownership before requesting or rotating a token:
 
-```text
-platform/data/operators/inter-hub/package-management
-  → field: inter-hub-pkg-rep
+```bash
+warden route find "publish kaizen-agentic to Forgejo PyPI" --json
 ```
 
-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).
+Never commit or copy the token into documentation, workplans, or State Hub.
 
 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).
+**Verified (2026-08-20):** the Forgejo index serves `kaizen-agentic==1.4.0`.
+A fresh virtual environment installed it with `--no-cache-dir` and the CLI reported
+version `1.4.0`.
 
 Verify secrets without cutting a release:
 
@@ -103,13 +94,13 @@ 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
+- [ ] `FORGEJO_PYPI_USER` and `FORGEJO_PYPI_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
+## Forgejo Actions Release
 
-The `.gitea/workflows/publish-python-package.yml` workflow publishes on tags
+The `.forgejo/workflows/publish-python-package.yml` workflow publishes on tags
 matching `v*`.
 
 Example:
@@ -135,11 +126,11 @@ 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
+  kaizen-agentic`) using the Forgejo 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/
+    --extra-index-url https://forgejo.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`).

docs/TELEMETRY.md

@@ -39,11 +39,11 @@ Potential v1.1 additions (not yet implemented):
 
 ## tele-mcp evaluation (deferred)
 
-[tele-mcp](https://gitea.coulomb.social/coulomb/tele-mcp) is a candidate MCP adapter
+[tele-mcp](https://forgejo.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 —
+User experience feedback uses [FEEDBACK.md](FEEDBACK.md) and Forgejo issue templates —
 separate from execution metrics.

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

@@ -22,7 +22,7 @@ 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`
+**File naming:** `workplans/KAIZEN-WP-NNNN-<slug>.md`
 **ID prefix:** `KAIZEN-WP`
 
 ### Required YAML frontmatter

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

@@ -186,5 +186,5 @@ same agent's project history.
 - [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)
+- [KAIZEN-WP-0003](../../workplans/KAIZEN-WP-0003-measurement-loop.md)
+- [KAIZEN-WP-0004](../../workplans/KAIZEN-WP-0004-ecosystem-integration.md)

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

@@ -37,14 +37,40 @@ 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>`
+  → durable work per (repo, agent)
+  → governed runner executes `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.
+does **not** fire cron, own the durable work queue, or invoke an LLM.
+
+### Current runtime realization (2026-08-20)
+
+The initial contract above remains valid, but the generic word “task” now has a
+specific durable implementation:
+
+```
+activity-core Temporal schedule/event
+  → rule evaluation and eligibility
+  → unique, idempotent ops_run with lease/retry state
+  → rein-local intake or caller receives bounded work
+  → kaizen-agentic schedule prepare <agent>
+  → Glas ExecutionRequest(harness_profile_ref=...)
+  → versioned profile resolves rein + model + sandbox + tool policy + limits
+  → bounded session and normalized execution evidence
+  → ops_run result + State Hub progress + .kaizen metrics/artifact evidence
+```
+
+`activity-core` owns schedule and durable work state. Task intake stays with
+the caller or rein where already implemented. A Kaizen blueprint or agent
+instance supplies an explicit, versioned `harness_profile_ref`; glas-harness
+resolves the concrete execution constellation and normalizes evidence; the
+selected rein owns its inner loop, backend policy, and credential use. Kaizen
+Agentic continues to own declaration, agent craft, preparation, and improvement
+evidence. A human-started coding-agent session remains a supported execution
+mode and reference smoke path.
 
 ### 1. Schedule manifest — `.kaizen/schedule.yml`
 
@@ -123,10 +149,15 @@ 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 scheduling or durable-queue code** in kaizen-agentic. Temporal schedules,
+  rule evaluation, and `ops_run` state 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.
+  Glas-selected rein executes it.
+- **No concrete rein/model selection.** Kaizen carries a versioned
+  `harness_profile_ref`; glas-harness resolves it without a hidden default.
+- **No runtime authority or credentials.** Those remain with Glas, the selected
+  rein, and the ecosystem credential/authorization owners.
 - **State-hub schema changes** (roster opt-in flag) are designed here but
   implemented in `the-custodian` (repo boundary).
 
@@ -134,7 +165,7 @@ kaizen-agentic schedule prepare <agent> [--target PATH] [--format markdown|json]
 
 - Operators declare per-repo schedules and a fleet roster without tribal
   knowledge.
-- activity-core can fire recurring tasks referencing `schedule prepare`.
+- activity-core can fire recurring durable work 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
@@ -147,4 +178,4 @@ kaizen-agentic schedule prepare <agent> [--target PATH] [--format markdown|json]
 - [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)
+- [KAIZEN-WP-0006](../../workplans/KAIZEN-WP-0006-scheduled-agent-execution.md)

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

@@ -71,4 +71,4 @@ Hybrid override manifest (option C) is design-only — see
 
 - 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)
+- [KAIZEN-WP-0008](../../workplans/KAIZEN-WP-0008-coulomb-loop-supplier-engagement.md)

docs/adr/ADR-007-forward-deployed-engagement-convention.md

@@ -127,16 +127,22 @@ should amend this ADR (or a successor), not re-open DEC-FDA-001 silently.
 
 ### Negative / trade-offs
 
-- Pilot vault currently sits in the supplier repo (`engagements/pilots/`) — must
-  still be treated as client confidential; export to client repo is recommended
-  before multi-tenant growth
-- activity-core automation for host duties is optional Phase 3 (manual prepare OK)
+- Pilot vault currently sits in the supplier repo (`engagements/pilots/`) under
+  transitional custody. The Railiance01 receiving authority is
+  `railiance-infra`; transfer requires explicit receiver acceptance before the
+  supplier copy is removed or reduced to a pointer.
+- Manual preparation remains supported. Unattended host duties require an
+  engagement-specific activity-core definition and an approved versioned Glas
+  `harness_profile_ref` in addition to the generic `ops_run` intake path.
 - Kai is not a payment processor; EUR path remains future work
 
 ### Follow-ups
 
-- Export pilot vault to client-owned path when railiance ops repo is ready
-- Optional activity-core ActivityDefinitions for daily host-operator prepare
+- Complete the proposed pilot transfer to the client-owned `railiance-infra`
+  evidence path and record its accepted commit
+- Register engagement-specific activity-core definitions and a Glas execution
+  profile reference for daily host-operator preparation when unattended
+  operation is desired
 - EUR commercial FX after 2–3 engagement calibration cycles
 
 ## Pilot evidence

docs/agency-framework.md

@@ -158,7 +158,7 @@ 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
+kaizen-agentic memory show project-assistant
 ```
 
 ---
@@ -242,7 +242,7 @@ All agents that do session-bound project work have `memory: enabled` in their fr
 
 | Agent | Category | Notes |
 |-------|----------|-------|
-| project-management | process | Reference implementation of the session protocol pattern |
+| project-assistant | process | Reference implementation of the session protocol pattern |
 | tdd-workflow | testing | |
 | requirements-engineering | process | |
 | scope-analyst | process | |
@@ -331,8 +331,12 @@ 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.
+**not** run cron, own durable work, or invoke an LLM. activity-core fires the
+schedule and creates `ops_run` work. Task intake remains rein-local where
+implemented. The blueprint/instance supplies a versioned
+`harness_profile_ref`; Glas resolves the concrete rein, model route, sandbox,
+tool policy, and limits and returns normalized evidence. Manual sessions remain
+a supported fallback.
 
 Schema: [integrations/schedule-schema.md](integrations/schedule-schema.md).
 
@@ -354,6 +358,6 @@ Schema: [integrations/schedule-schema.md](integrations/schedule-schema.md).
 - [engagements/pilots/eng-coulomb-railiance01-ho-001](../engagements/pilots/eng-coulomb-railiance01-ho-001/) — Phase 1 pilot tree
 - [wiki/ForwardDeployedAgencyBusinessModel.md](../wiki/ForwardDeployedAgencyBusinessModel.md) — Kai trial currency, seats/duties, confidentiality
 - [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)
+- [WP-0002: Agency Framework](../workplans/KAIZEN-WP-0002-agency-framework.md)
+- [WP-0003: Measurement Loop](../workplans/KAIZEN-WP-0003-measurement-loop.md)
+- [WP-0004: Ecosystem Integration](../workplans/KAIZEN-WP-0004-ecosystem-integration.md)

docs/assessments/2026-08-20-intent-role-automation-readiness.md

@@ -0,0 +1,562 @@
+# INTENT Alignment and Role-Agent Automation Readiness
+
+**Date:** 2026-08-20
+
+**Workplan:** KAIZEN-WP-0012
+
+> **Execution-boundary update, 2026-08-21:** This assessment captured the
+> then-live activity-core → rein-aharness intake path. GLAS-WP-0004 subsequently
+> proved contract 1.0 across two rein/model constellations. Kaizen blueprints
+> and agent instances should now hand a versioned `harness_profile_ref` to
+> glas-harness rather than encode a concrete rein, provider, model, or sandbox.
+> Scheduling remains with activity-core and task/blueprint intake remains
+> caller- or rein-local; the assessment's ownership and budget findings remain
+> valid.
+
+**Assessment:** materially aligned, operationally useful, not yet at the full
+`INTENT.md` maturity target
+
+## Executive assessment
+
+KaizenAgentic has grown beyond the prompt library described by the previous
+`SCOPE.md`. It now provides most of the **blueprint and improvement-contract
+layer** required by `INTENT.md`: versioned agent definitions, project memory,
+protocols, execution metrics, feedback, optimizer recommendations, schedule
+manifests, preparation bundles, engagement conventions, and a pilot Role
+package.
+
+The strategic boundary remains sound. KaizenAgentic should not absorb runtime,
+scheduling, credentials, authorization, or durable task lifecycle. Those pieces
+now exist elsewhere:
+
+- **role-engine** defines organizational roles;
+- **activity-core** schedules activity and emits durable claimable `ops_run`
+  work;
+- **rein-aharness** claims work and runs governed agent sessions;
+- **llm-connect** supplies provider-neutral model execution;
+- identity, OpenBao/credential routing, and policy systems control access;
+- State Hub and repo-local `.kaizen/` state retain coordination and improvement
+  evidence.
+
+The missing link is a governed, machine-readable chain from a role definition
+through an authorized goal and constrained workforce allocation to a specific
+agent assignment and executable instance. The runtime path itself is no longer
+hypothetical: activity-core's queue and rein-aharness's generic `agent-session`
+approach are implemented. However, the current queue payload and harness intake
+do not carry an explicit goal, leader, role, assignment, budget envelope, or
+arbitrary agent-instance reference. Rein-aharness currently infers the agent
+from a small fixed definition/label map and otherwise defaults to `coach`.
+
+## Naming and ownership finding
+
+No repository, service, or contract named `role-manager` was found in the
+workspace on 2026-08-20. The current role-definition repository is
+**role-engine**; its `INTENT.md` is still marked Draft.
+
+This matters because role-engine's `INTENT.md` explicitly says:
+
+- roles are not identities;
+- role definitions do not grant permissions;
+- live assignment, scheduling, and workflow execution are out of scope;
+- machinery should be added only for demonstrated consumer requirements.
+
+Therefore “roles as defined by role-manager” is treated here as “roles defined
+by role-engine.” `agentic-resources` is the best-fit existing repository to
+become the **agent workforce and assignment manager**, subject to an explicit
+INTENT/SCOPE decision there. That preserves role-engine's catalog boundary and
+avoids introducing a role-manager service before a separate runtime service is
+actually needed. Consumer-owned assignment manifests can remain the durable
+source while agentic-resources indexes, plans, and governs the portfolio.
+
+## Agentic-resources and human-resources finding
+
+`agentic-resources` is **not intent-only**, although its root `SCOPE.md` is a
+stale generated placeholder. Its finished AGENTIC-WP-0002 through WP-0011 work
+implements a substantial Helix Forge loop:
+
+- capture and normalize Claude, Codex, and Grok coding sessions;
+- retain raw/digested memory within storage budgets;
+- detect cost, failure, success, and infrastructure-friction signals;
+- curate evidence-backed solution patterns with human approval;
+- distribute approved patterns into agent environments;
+- measure before/after effectiveness and fleet trends;
+- publish weekly retrospectives and correlate with Kaizen project metrics.
+
+That is already an **agent performance and development** subsystem. It is a
+natural foundation for agent inventory, selection, assignment, capacity
+planning, performance review, development, reallocation, and retirement. It
+does not currently implement those workforce-management records, nor does its
+current session-memory code understand organizational goals or financial
+budget envelopes.
+
+`human-resources` is the useful sibling model, but is much earlier: its current
+implementation is a draft workflow registry and assessment loop covering
+current-state inventory, automation potential, human-touch boundaries, and
+readiness. Its INTENT explicitly includes human goal-setting, feedback,
+coaching, compensation, workforce planning, and development. The two resource
+systems should share vocabulary where useful—goal assignment, accountability,
+capacity, performance evidence, development plan, lifecycle—without combining
+human-sensitive records with agent telemetry or pretending humans and agents
+have identical authority and welfare concerns.
+
+Recommended boundary for agentic-resources:
+
+- **Own:** agent workforce inventory, fit/selection evidence, assignments,
+  capacity allocations, performance/development plans, portfolio reviews, and
+  rebalance/retirement recommendations.
+- **Consume:** leadership goals and mandates, role-engine definitions, Kaizen
+  blueprints/metrics, fin-hub constraints, resource-control evidence, State Hub
+  work/outcomes, and runtime status.
+- **Do not own:** company strategy, the meaning of organizational roles,
+  financial truth or spending authority, resource procurement, credentials,
+  scheduling, or execution.
+
+## Assessment against INTENT.md
+
+| INTENT commitment | Current evidence | Assessment |
+|---|---|---|
+| Canonical mission and operating model | `INTENT.md`, wiki, ADRs, agency and engagement documents | Strong |
+| KaizenAgent definition template | Template exists; authoring/docs CLI and 20 packaged definitions exist | Partial: the reference fleet still uses less structure than the full template |
+| Meta-optimizer concept | `OptimizationLoop`, metrics summaries, `metrics optimize`, feedback and correlation | Strong foundation; refinement approval/version rollout is not closed-loop |
+| Measurable behavior | Execution JSONL, summaries, engagement metrics, event and artifact publication | Implemented, but coverage depends on callers recording closeout evidence |
+| Idempotent behavior | Idempotency keys exist in engagement closeout and downstream `ops_run`; validation is repeatable | Partial: generic blueprint definitions do not yet declare convergence/idempotency semantics uniformly |
+| Codebase improvement guidance | Specialized agents, protocols, templates, tutorials, integration patterns | Useful reference implementation; machine-checkable guidance model remains incomplete |
+| Relationship among prompts, experiments, mantras, agents, capabilities | Conceptual material and capability metadata exist | Partial: relationships are documented more than schema-validated |
+| Product, pricing, revenue, and brand framing | Agency model, Role packages, Kai pilot settlement, wiki framing | Present at pilot level; not yet a repeatable commercial operating system |
+| Versioned, testable, reversible units | Package releases, Git history, tests, Role version, ADRs | Strong for code and packages; blueprint compatibility/pinning needs a formal contract |
+| Define → deploy → measure → refine → commercialize | Define/deploy/measure are operational; refine and commercialize have working pieces | Maturity target not yet complete |
+
+### Design-principle fit
+
+- **Continuous improvement:** directly represented in metrics, feedback, memory,
+  optimization, and engagement closeout.
+- **Measurable by default:** supported by tooling, but not yet mandatory in every
+  agent definition or automated run result.
+- **Idempotent operations:** present in selected workflows, not expressed as a
+  required blueprint field or verified per duty.
+- **Evidence over intuition:** strong conventions and event/artifact paths exist;
+  optimizer recommendations still require a clearer promotion gate.
+- **Separation of concerns:** strong and increasingly proven by the
+  activity-core / rein-aharness split.
+- **Composable capabilities:** agents, protocols, memory, schedules, Roles, and
+  integrations are composable, though their shared schema is fragmented.
+- **Human-readable and machine-executable:** human-readable coverage is strong;
+  role-engine roles are not yet machine-readable enough for safe compilation.
+- **Rollback-ready evolution:** Git/package rollback exists; assignment,
+  blueprint pinning, and canary policy need standardization.
+- **Compounding value:** evidence can accumulate, but automatic evidence →
+  approved blueprint revision → controlled rollout is not closed.
+
+## What already works end to end
+
+The ecosystem has the following proven backbone:
+
+```text
+activity-core Temporal schedule/event
+        │
+        ▼
+rule action → durable ops_run (idempotent, lease/claim/retry)
+        │
+        ▼
+rein-aharness claim-loop → approach selection
+        │
+        ▼  labels/approach_hint = agent-session
+repo instance policy → kaizen-agentic schedule prepare
+        │
+        ▼
+bounded LLM session → local commit verification
+        │
+        ▼
+ops_run result + State Hub progress + .kaizen metrics
+```
+
+Important existing controls include:
+
+- unique per-fire `ops_run` idempotency keys;
+- atomic claim with lease, heartbeat API, retry, and terminal failure;
+- target-repository mapping on the harness host;
+- named tool profiles, autonomy lanes, token budgets, and harness-major pins;
+- offline blueprint/memory/metrics preparation;
+- local commit verification and no-push runtime policy;
+- completion metadata and artifact links in activity-core;
+- per-agent metrics and State Hub progress reporting.
+
+This means the next work is integration and governance, not building another
+scheduler or agent runtime.
+
+## Goal, leadership, and budget governance spine
+
+Role automation needs a control hierarchy above the execution backbone:
+
+```text
+organizational intent
+        ↓
+leadership-owned goals and outcome measures
+        ↓
+financial/resource/attention envelopes
+        ↓
+agentic-resources workforce plan and RoleAssignment
+        ↓
+Kaizen blueprint + consumer-owned AgentInstance
+        ↓
+activity-core scheduled duty → rein-aharness bounded run
+        ↓
+outcome, cost, evidence, escalation
+        ↓
+leadership review + workforce rebalance + blueprint improvement
+```
+
+There is no single generic goal/leadership repository in the current
+workspace. Goal authority is contextual. For Binky Hedgehog GmbH,
+`binky-control` is the ratified company brain: it owns company intent, success
+milestones, autonomy lanes, decision queues, and the founder-attention budget.
+Other organizations or clients need an equivalent accountable control source.
+Agentic-resources may translate a goal into workforce allocation, but it must
+not invent or silently reprioritize strategic goals.
+
+Leadership is an accountable relationship, not a prompt adjective. A
+`LeadershipMandate` should identify:
+
+- the organization/engagement and accountable leader or leadership agent;
+- the goal(s) the leader may decompose and the outcomes it must preserve;
+- decision rights, delegation depth, and prohibited commitments;
+- who may approve, pause, reallocate, or terminate work;
+- reporting/review cadence and the escalation chain;
+- conflict-resolution order when goals or constraints compete;
+- the time/attention budget expected from human reviewers.
+
+An agent may lead other agents only inside this mandate. Role wording alone
+must never create authority, and a leadership agent cannot widen its own budget
+or tool grants.
+
+### Budget layers and enforcement
+
+“Budget” must not collapse into one token integer:
+
+| Constraint | Authority/source | Allocation/control | Hard enforcement |
+|---|---|---|---|
+| Monetary budget, commitments, burn, runway | `fin-hub` | Leadership plus agentic-resources consume bounded constraint signals | Financial/approval systems; no autonomous spend outside an approved envelope |
+| Infrastructure/model capacity and technical economics | `resource-control` | Agentic-resources uses forecasts, allocations, and optimization evidence | Platform/provider quotas and owning operators |
+| AI-plan entitlement and booked effectiveness | `fin-hub`, joined to State Hub token evidence | Portfolio review and model/profile selection | Provider entitlement plus runtime policy |
+| Per-run tokens and wall time | Delegated `ResourceEnvelope` | Agent instance/duty allocation | rein-aharness / llm-connect budget tracker and timeout |
+| Concurrent agents and duty capacity | Agentic-resources workforce plan | Assignment allocator | activity-core eligibility plus harness worker/profile limits |
+| Human attention and decision load | Organization leadership source; Binky example in `binky-control` | Decision batching and escalation policy | Approval queues and office-hour/autonomy lanes |
+
+Fin-hub already exposes provenance-bearing budget-ceiling, commitment,
+burn-pressure, and runway-pressure signals and owns booked AI-plan cost and
+entitlements. Resource-control explicitly defers budget authority to fin-hub
+and owns resource demand, capacity, utilization, allocation, and technical cost
+evidence. Agentic-resources should consume both and allocate agent capacity
+within them; it should not create a parallel money ledger or procurement
+authority.
+
+The shared `ResourceEnvelope` should support:
+
+- stable ID, authority/source reference, period, scope, and currency/unit;
+- hard ceiling, soft target, warning thresholds, and reserve;
+- financial, token, wall-time, concurrency, and human-attention dimensions;
+- amount allocated, committed, consumed, forecast, and remaining, with unknown
+  distinct from zero;
+- allowed reallocation authority and approval threshold;
+- cost-attribution key and goal/assignment/duty correlation;
+- exhaustion behavior: refuse, degrade, defer, or prepare an approval package;
+- evidence timestamps and supersession/version links.
+
+Activity-core should schedule only eligible allocations, while rein-aharness
+enforces the per-run slice. Agentic-resources controls the period/portfolio
+allocation and proposes rebalancing. Leadership decides goal priority and any
+material budget or authority change.
+
+## The missing role-to-run contract
+
+The following records must remain distinct even when one manifest references
+several of them:
+
+| Record | Question answered | Recommended owner |
+|---|---|---|
+| `RoleDefinition` | What outcomes, duties, authority, interfaces, and evidence define the role? | role-engine |
+| `AgentBlueprint` / executable Role package | How can an agent perform a safe subset of those duties? | kaizen-agentic |
+| `StrategicGoal` | What outcome matters, why, by when, and how will success be judged? | Accountable organization/engagement leadership source |
+| `LeadershipMandate` | Who may decompose the goal, direct work, decide, and escalate? | Accountable organization/engagement leadership source |
+| `ResourceEnvelope` | Which financial, token, time, capacity, and attention constraints apply? | Fin-hub/resource-control/leadership facts composed into a delegated envelope |
+| `RoleAssignment` | Which agent instance fills which role, for which goals, within which mandate and envelope? | Recommended: agentic-resources, with consumer-owned manifest as source |
+| `AgentInstance` | Which blueprint, cadence, lane, profile, budget, memory, and runtime pin apply? | Consuming repository, validated by kaizen-agentic and the selected rein |
+
+The first implementation should define a versioned `RoleAssignment` contract
+with at least:
+
+- stable assignment ID and lifecycle state;
+- `goal_refs`, accountable outcome owner, and leadership-mandate reference;
+- `role_ref` containing role ID plus immutable revision/version;
+- `blueprint_ref` containing agent name plus package/version or content digest;
+- client/tenant and one or more target references;
+- duty selection: only the role duties delegated to this agent;
+- expected outputs and evidence for each duty;
+- cadence/event trigger references and timezone;
+- autonomy lane, named tool profile, token/time budget, and harness-major pin;
+- resource-envelope references plus duty-level allocation and exhaustion policy;
+- credential-route **references**, never secret values;
+- approval and escalation rules derived from role decision rights;
+- memory/metrics custody location and retention classification;
+- start/end dates, pause/disable switch, owner, and rollback revision.
+
+## Required changes by repository
+
+### Organization leadership/control source
+
+1. Publish stable goal and leadership-mandate records with accountable owners,
+   outcomes, measures, priority, horizon, decision rights, and escalation.
+2. Delegate bounded financial, capacity, token, time, and attention envelopes;
+   do not express “use judgment” as unlimited authority.
+3. Resolve cross-goal priority and approve material reallocation, spending,
+   external commitments, or expansion of autonomy.
+4. For the Binky company context, reuse `binky-control` intent, milestones,
+   autonomy lanes, decision packages, and founder-attention policy instead of
+   creating parallel company governance in an agent repository.
+
+### agentic-resources
+
+1. Deliberately refine INTENT/SCOPE from the implemented Helix Forge
+   session-improvement subsystem into an agent-workforce control boundary.
+2. Define agent inventory, `RoleAssignment`, capacity allocation,
+   performance/development plan, portfolio review, and retirement contracts.
+3. Match roles and blueprints to delegated goals using evidence; record why an
+   assignment is suitable and which role duties remain unstaffed.
+4. Consume fin-hub constraint signals and resource-control evidence to allocate
+   period budgets without copying financial or resource ledgers.
+5. Aggregate run outcomes/costs by goal, role, assignment, and duty; recommend
+   continue, coach/refine, reallocate, pause, or retire.
+6. Require leadership approval for goal reprioritization, material envelope
+   changes, and authority expansion.
+
+### human-resources
+
+1. Reuse compatible goal, accountability, capacity, review, and development
+   vocabulary where it helps human/agent collaboration.
+2. Keep human-sensitive records, compensation, welfare, employment, and
+   relational judgment separate from agent telemetry and automated scoring.
+3. Represent mixed human-agent teams and handoffs without treating people as
+   interchangeable compute resources.
+
+### role-engine
+
+1. Add stable revision metadata or a small machine-readable companion format
+   after agreeing the consumer need.
+2. Structure at least duties, cadence suggestions, decision rights,
+   escalations, interfaces, and success evidence.
+3. Preserve the human-readable role contract as authoritative.
+4. Do **not** add assignment, credentials, or scheduling merely to make the
+   catalog look executable.
+
+### kaizen-agentic
+
+1. Define a `role_ref` and duty-coverage mapping for executable Role packages.
+2. Reconcile the local `roles/<id>/ROLE.yaml` concept with role-engine: the
+   former should be a derived execution package, not a competing organizational
+   role source.
+3. Add a compiler/scaffolder that consumes a pinned role definition plus an
+   assignment, goal, mandate, and resource-envelope references and produces:
+   - a bound agent blueprint;
+   - protocols and success metrics;
+   - `.kaizen/schedule.yml` base/runtime fields;
+   - activity-core definition/rule fragments;
+   - validation evidence showing which role duties are covered or excluded.
+4. Add schema validation for blueprint version, role revision, idempotency,
+   expected output, evidence, goal traceability, budget/refusal behavior, and
+   escalation metadata.
+5. Close the improvement promotion loop: evidence → proposed blueprint change →
+   tests/evaluation → human approval → versioned canary → rollback or promote.
+
+### activity-core
+
+1. Keep schedule and queue ownership.
+2. Extend the task/`ops_run` contract with structured execution metadata instead
+   of encoding it only in labels or prose. Minimum useful fields are
+   `goal_refs`, `leadership_mandate_ref`, `resource_envelope_ref`,
+   `assignment_id`, `role_id`, `duty_id`, `agent_instance`, `blueprint_ref`,
+   `expected_output`, allocated run budget, and a correlation/run key.
+3. Emit `labels: [automated, agent-session]` and
+   `approach_hint: agent-session` for governed agent sessions.
+4. Resolve only active, enabled assignments and generate a unique run for each
+   `(assignment, duty, target, scheduled fire)`.
+5. Keep prompts, credentials, and raw model output out of `ops_run` records.
+
+### rein-aharness
+
+1. Keep runtime, credentials, policy enforcement, and claim execution ownership.
+2. Replace fixed label-to-agent inference for role sessions with an explicit
+   validated `agent_instance`/blueprint reference from the run contract.
+3. Verify the run's assignment is active and its role/blueprint/runtime versions
+   match the repo manifest; refuse expired mandates or envelopes.
+4. Enforce duty-level tool profile, target allow-list, budget, timeout,
+   concurrency, and escalation policy.
+5. Return compact structured evidence: outcome, artifact path, commit, target,
+   goal/blueprint/role/assignment revisions, allocated/consumed budget,
+   metrics, and refusal/escalation reason.
+6. Separate deterministic connectors from the LLM session. For example,
+   Telegram collection or publishing should be bounded adapters; the model
+   should receive prepared data and should not gain arbitrary network access.
+
+### State Hub and policy/identity systems
+
+1. Index goals, mandates, envelopes, assignments, and correlation IDs without
+   becoming their authoritative source or the runtime.
+2. Connect `goal → assignment → activity_run → ops_run → harness execution →
+   artifact/commit → kaizen metrics → workforce review` for audit.
+3. Represent human-needed/refused/escalated outcomes explicitly.
+4. Route credential needs through the catalog/OpenBao path and enforce technical
+   authorization independently of role wording.
+
+### fin-hub and resource-control
+
+1. Fin-hub remains authoritative for monetary budgets, commitments, burn,
+   runway, AI-plan booked cost, entitlement, and viability signals.
+2. Resource-control remains authoritative for resource identity, demand,
+   capacity, utilization, allocation evidence, and technical economics.
+3. Expose provenance-bearing constraints with stable period/scope keys so
+   agentic-resources can allocate without guessing or treating unknown as zero.
+4. Accept goal/assignment/duty attribution on usage and outcome evidence while
+   keeping allocation evidence distinct from booked spend.
+
+## Proposed instance shape
+
+This is a **target contract**, not the current kaizen schedule schema:
+
+```yaml
+version: "2"
+timezone: Europe/Berlin
+harness: 0
+assignments:
+  community-manager-coulomb:
+    goal_refs:
+      - binky-control:goal:coulomb-community-health
+    leadership_mandate_ref: binky-control:mandate:community-operations
+    accountable_outcome_owner: founder
+    role_ref:
+      repository: role-engine
+      id: community-manager
+      revision: "<immutable-git-revision>"
+    blueprint_ref:
+      name: community-manager
+      package_version: "<kaizen-agentic-version>"
+    target: coulomb-society-operations
+    resource_envelopes:
+      financial: fin-hub:budget:coulomb-community:2026-Q3
+      capacity: agentic-resources:envelope:community-ops:2026-W34
+      attention: binky-control:attention:founder:2026-W34
+    duties:
+      weekly-community-health:
+        goal_ref: binky-control:goal:coulomb-community-health
+        cadence: weekly
+        cron: "0 9 * * 1"
+        enabled: true
+        expected_output: reports/community-health/YYYY-MM-DD.md
+        lane: green
+        tool_profile: community-observe-report
+        run_budget_tokens: 40000
+        run_timeout_seconds: 900
+        exhaustion: defer-and-report
+        approval: none
+      publication-draft:
+        cadence: weekly
+        enabled: false
+        expected_output: outbox/community-update-YYYY-MM-DD.md
+        lane: green
+        tool_profile: community-draft-only
+        run_budget_tokens: 30000
+        approval: human-before-publish
+```
+
+The assignment compiler could initially render this into the current v1
+`.kaizen/schedule.yml` plus an activity-core definition. Moving the base
+schedule schema to v2 should happen only after kaizen-agentic, activity-core,
+and rein-aharness agree the fields and compatibility path.
+
+## Recommended first pilot
+
+Use role-engine's only current role, `community-manager`, but automate a narrow,
+low-risk duty rather than claiming the entire role is autonomous.
+
+**Pilot duty:** produce a weekly community-health brief from an approved,
+read-only snapshot of community activity.
+
+**Why this duty:** it exercises role revision, assignment, scheduled intake,
+blueprint preparation, evidence metrics, and escalation without granting
+publishing, moderation, sanctions, membership, or direct messaging authority.
+
+Pilot sequence:
+
+1. Pin the role-engine revision and identify which Community Manager success
+   criteria the brief measures.
+2. Record the leadership-owned goal, accountable outcome owner, review cadence,
+   and bounded financial/capacity/attention envelopes.
+3. Have agentic-resources create the assignment and allocate a weekly duty/run
+   budget without copying the authoritative budget ledger.
+4. Create a Kaizen blueprint/protocol and tests for evidence quality,
+   provenance, privacy handling, and “insufficient evidence” refusal.
+5. Create a consumer-owned assignment and strict read/report-only instance.
+6. Have a deterministic adapter place a sanitized activity snapshot in the
+   target repo or artifact input; do not expose general Telegram credentials to
+   the model session.
+7. Register an activity-core weekly definition that emits an `agent-session`
+   run with explicit assignment and duty identity.
+8. Run through rein-aharness, producing only a local report commit.
+9. Require human review and measure correctness, provenance, usefulness,
+   false assertions, runtime, tokens, and escalation quality.
+10. Review goal progress and envelope burn through agentic-resources; reallocate
+    or pause if marginal value is poor or leadership priorities change.
+11. Complete five clean scheduled/forced cycles before removing any manual
+   fallback or considering a write-capable duty.
+
+Only after the observation/reporting pilot is stable should the system add
+drafting to a human-reviewed outbox. Automatic publishing or moderation should
+remain separate, more privileged duties with explicit policy and approval.
+
+## Operational definition of “fully automated”
+
+For this system, fully automated should mean:
+
+- the schedule/event fires without a person;
+- an eligible assignment resolves deterministically;
+- work is emitted once, claimed safely, and retried within policy;
+- the exact role, duty, blueprint, target, runtime, and policy versions are
+  known before execution;
+- the run traces to a leadership-owned goal, accountable owner, active mandate,
+  and unexpired resource envelope;
+- portfolio and per-run financial/token/time/attention constraints are checked,
+  with unknown never treated as unlimited or zero;
+- the agent receives bounded context and tools;
+- success is verified against an explicit output/evidence contract;
+- results and costs are correlated and reviewable;
+- refusal, escalation, pause, rollback, and lease recovery work without manual
+  database repair.
+
+It should **not** mean that every responsibility in a human role is delegated or
+that role wording grants technical authority. A role can be fully scheduled
+while only its safe, explicitly assigned duties are automated.
+
+## Recommended implementation order
+
+1. **Ownership decisions:** confirm role-engine as definition source,
+   agentic-resources as agent-workforce/assignment owner, and the contextual
+   leadership source for goals and mandates.
+2. **Governance contracts:** StrategicGoal, LeadershipMandate,
+   ResourceEnvelope, RoleAssignment, role-to-blueprint coverage, and structured
+   `ops_run` execution context.
+3. **Constraint integration:** consume fin-hub budget/viability signals,
+   resource-control capacity evidence, and organization attention/autonomy
+   policy without duplicating their authority.
+4. **Adapters and validation:** Kaizen compiler/scaffolder, agentic-resources
+   allocator, and explicit role-agent intake in rein-aharness.
+5. **Read-only pilot:** Community Manager weekly health brief, human-reviewed,
+   goal- and budget-correlated, for five clean cycles.
+6. **Production controls:** dashboards, alerts, retry/dead-letter policy,
+   pause/rollback, version canary, secret-route/policy audit.
+7. **Improvement closure:** use measured pilot evidence to rebalance the agent
+   portfolio and version/canary a blueprint refinement without rewriting the
+   leadership goal or source role contract.
+
+This route reuses the platform that is already live, preserves each
+repository's stated intent, and concentrates new work on the genuinely missing
+capability: goal-directed, leadership-accountable, budget-constrained agent
+workforce allocation.

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

@@ -106,4 +106,4 @@ kaizen-agentic metrics record coach --success --time 60 --quality 0.9 --emit-eve
 
 - [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)
+- [KAIZEN-WP-0008](../../workplans/KAIZEN-WP-0008-coulomb-loop-supplier-engagement.md)

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

@@ -1,9 +1,18 @@
 # activity-core Handoff — Scheduled Agent Execution (WP-0006)
 
+> **Historical supplier handoff, completed for the initial resolver/pilot path.**
+> The initial production composition used activity-core durable `ops_run` work
+> claimed by rein-aharness through its generic `agent-session` approach. Glas
+> contract 1.0 now defines the rein-neutral execution boundary: new blueprint
+> and agent-instance handoffs should carry a versioned `harness_profile_ref`.
+> The resolver and preparation contracts below remain compatible inputs.
+
 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).
+ActivityDefinition **drafts**; activity-core owns the resolver, schedule firing,
+and durable work creation (repo boundary, ADR-005). Task intake remains
+rein-local where implemented; glas-harness owns explicit execution-profile
+resolution and normalized evidence.
 
 Open this as an activity-core issue/PR titled *"Enable kaizen scheduled agent
 execution (WP-0006)"* and track the boxes there.
@@ -56,7 +65,7 @@ in kaizen-agentic drafts) when engagement moves beyond coulomb-loop bootstrap co
 - [ ] 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)
+## Smoke test (manual reference path)
 
 ```bash
 cd /path/to/pilot-repo
@@ -68,6 +77,9 @@ 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`.
+For unattended operation, confirm the resulting `ops_run` is claimable, the
+blueprint/instance provides an approved `harness_profile_ref`, and Glas resolves
+it without a hidden rein/model fallback before enabling the schedule broadly.
 
 ## Pilot roster
 
@@ -79,4 +91,4 @@ Then in activity-core: run the resolver (dry-run) and confirm one
 
 - [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)
+- [KAIZEN-WP-0006](../../workplans/KAIZEN-WP-0006-scheduled-agent-execution.md)

docs/integrations/customer-engagement-playbook.md

@@ -2,7 +2,7 @@
 
 How kaizen-agentic supports a **customer engagement repo** for **improvement
 loops** (reference:
-[coulomb-loop](https://gitea.coulomb.social/coulomb/coulomb-loop)). Second loop
+[coulomb-loop](https://forgejo.coulomb.social/coulomb/coulomb-loop)). Second loop
 engagements should copy [customer-engagement-repo-layout.md](customer-engagement-repo-layout.md)
 and complete the checklist in one session.
 
@@ -93,8 +93,8 @@ kaizen-agentic schedule init --engagement <slug> --bootstrap-cadence weekly --fo
 
 ## 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)
+- Customer: [coulomb-loop INTENT](https://forgejo.coulomb.social/coulomb/coulomb-loop/src/branch/main/INTENT.md)
+- Supplier workplan: [KAIZEN-WP-0008](../../workplans/KAIZEN-WP-0008-coulomb-loop-supplier-engagement.md)
 - Convention: [ADR-006](../adr/ADR-006-customer-engagement-convention.md)
 
 ## Related

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

@@ -2,7 +2,7 @@
 
 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).
+[coulomb-loop](https://forgejo.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.
@@ -62,4 +62,4 @@ See [customer-engagement-playbook.md](customer-engagement-playbook.md).
 
 - 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)
+- [KAIZEN-WP-0008](../../workplans/KAIZEN-WP-0008-coulomb-loop-supplier-engagement.md)

docs/integrations/forward-deployed-engagement-playbook.md

@@ -87,7 +87,10 @@ kaizen-agentic engagement close-session eng-... \
 
 ### 7. Operate cadence
 
-- Enable entries in engagement `schedule.yml` (manual prepare until activity-core)
+- Enable entries in engagement `schedule.yml`; they declare intent but do not
+  activate unattended work by themselves
+- Continue manual prepare until an engagement-specific activity-core definition
+  and versioned Glas execution profile have passed a bounded smoke test
 - Daily: health + load; weekly: OS/security pass (privileged changes still gated)
 
 ### 8. Ramp-down (when ending)
@@ -116,7 +119,7 @@ Friction and resolutions from `eng-coulomb-railiance01-ho-001` / KAIZEN-WP-0009.
 | `k3s kubectl` ServiceUnavailable under memory pressure | Record as finding; avoid hammering API; re-sample after capacity relief |
 | Nested `.kaizen/metrics` under engagement is correct for custody | Root `.gitignore` `.kaizen/metrics/` only ignores repo-root metrics; pilot metrics are commit-able |
 | Privileged work tempting on Critical host | RU-08 = **proposal dry-run only** until human approval table filled |
-| Pilot vault in supplier repo | Treat as client confidential; export to client ops repo before multi-tenant scale |
+| Pilot vault in supplier repo | Treat as client confidential; target `railiance-infra` for Railiance01 and require receiver acceptance before source cleanup |
 | activity-core not required for Phase 1 | Manual `prepare` + `close-session`; schedule.yml documents intent |
 | Kai charges felt real only after close-session | Always close-session after live duties; quote alone is not spend |
 | High load makes remote `du`/`apt` slow | Prefer short command batches; timeout ≥60s for full assessments |
@@ -152,14 +155,22 @@ ssh railiance01 "sudo ufw allow from <PUBLIC_IP> to any port 6443 proto tcp comm
 
 ---
 
-## Optional activity-core wiring (Phase 3)
+## Optional unattended wiring (Phase 3)
 
 Not required for operate. When ready:
 
-1. Customer or engagement repo owns ActivityDefinition copies that shell out to
-   `kaizen-agentic engagement prepare <id>` then start a coding-agent session
-2. Resolver points at engagement id / host Target (new work — not WP-0009)
-3. Keep privilege gates in the agent definition regardless of cron fire
+1. Customer or engagement repo owns the ActivityDefinition that identifies the
+   engagement and emits idempotent, claimable `ops_run` work in activity-core.
+2. The run or bound agent instance carries organizational references and an
+   approved versioned `harness_profile_ref`; it does not carry secrets or raw
+   provider prompts.
+3. Rein-local intake or another caller claims/receives the work and constructs
+   the Glas `ExecutionRequest`. Glas resolves the concrete rein, model, sandbox,
+   tool policy, and limits; the selected rein executes
+   `kaizen-agentic engagement prepare <id>` inside the bounded session.
+4. Completion links the `ops_run`, engagement report, metrics, and State Hub
+   progress without duplicating confidential content into coordination records.
+5. Keep privilege gates in the agent definition regardless of schedule fire.
 
 ---
 

engagements/pilots/eng-coulomb-railiance01-ho-001/.kaizen/metrics/host-operator/executions.jsonl

@@ -2,3 +2,5 @@
 {"agent": "host-operator", "duty": "deep_assessment", "engagement_id": "eng-coulomb-railiance01-ho-001", "execution_time_s": 900.0, "phase": "operating", "quality_score": 0.9, "success": true, "timestamp": "2026-07-16T10:42:51Z"}
 {"agent": "host-operator", "duty": "deep_assessment", "engagement_id": "eng-coulomb-railiance01-ho-001", "execution_time_s": 1200.0, "phase": "operating", "quality_score": 0.88, "success": true, "timestamp": "2026-07-16T11:05:17Z"}
 {"agent": "host-operator", "duty": "standard_review", "engagement_id": "eng-coulomb-railiance01-ho-001", "execution_time_s": 60.0, "phase": "operating", "quality_score": 0.7, "success": true, "timestamp": "2026-07-16T12:33:33Z"}
+{"agent": "host-operator", "duty": "short_assist", "engagement_id": "eng-coulomb-railiance01-ho-001", "execution_time_s": 30.0, "phase": "operating", "quality_score": 0.8, "success": true, "timestamp": "2026-07-21T02:14:41Z"}
+{"agent": "host-operator", "duty": "short_assist", "engagement_id": "eng-coulomb-railiance01-ho-001", "execution_time_s": 180.0, "phase": "operating", "quality_score": 0.75, "success": true, "timestamp": "2026-07-21T22:37:48Z"}

engagements/pilots/eng-coulomb-railiance01-ho-001/.kaizen/metrics/host-operator/summary.json

@@ -1,12 +1,12 @@
 {
   "agent": "host-operator",
-  "avg_execution_time_s": 541.25,
-  "avg_quality_score": 0.795,
-  "execution_count": 4,
-  "last_execution": "2026-07-16T12:33:33Z",
+  "avg_execution_time_s": 395.833,
+  "avg_quality_score": 0.788,
+  "execution_count": 6,
+  "last_execution": "2026-07-21T22:37:48Z",
   "success_rate": 1.0,
   "trend": {
-    "quality_score": "stable",
+    "quality_score": "up",
     "success_rate": "stable"
   }
 }

engagements/pilots/eng-coulomb-railiance01-ho-001/CUSTODY.md

@@ -0,0 +1,52 @@
+# Custody — eng-coulomb-railiance01-ho-001
+
+## Decision
+
+The engagement record and vault are owned by the `coulomb` client and classified
+`client_confidential`. Their present location in `kaizen-agentic` is
+transitional supplier custody, not supplier ownership.
+
+The selected receiving authority is:
+
+```text
+repository: railiance-infra
+path: docs/evidence/resource-hosteurope-railiance01/engagements/
+      eng-coulomb-railiance01-ho-001/
+```
+
+`railiance-infra` is the canonical S1 owner for Railiance01 inventory,
+hardening, access, and host-operational evidence, and already maintains the
+`resource-hosteurope-railiance01` evidence interface. `reef-railiance` is not
+the target: it owns grouped reef identity, topology, and bindings, not detailed
+host-operation records.
+
+## Current data classes
+
+| Tree | Classification | Intended custody |
+|------|----------------|------------------|
+| `ENGAGEMENT.yaml`, request, schedule, bound definition | client operational record | receiving repo |
+| `vault/`, reports, checklists, access plan | client confidential | receiving repo |
+| engagement-local `.kaizen/metrics/` | client execution evidence | receiving repo |
+| `commercial/` | client settlement metadata | receiving repo or financial authority |
+| reusable role craft under `roles/host-operator/` | supplier craft | remains in kaizen-agentic |
+
+The committed access plan contains operational routing and host identity, but
+no credential value. Secrets, private keys, tokens, and passwords must never be
+added to this tree or to a transfer package.
+
+## Transfer gate
+
+The supplier copy remains the source of truth until all of these are true:
+
+1. The receiving repository accepts the path and confidentiality policy.
+2. The complete engagement tree is copied with history or an attributable
+   import commit, and the receiver validates its manifest.
+3. The receiver records the accepted commit and acceptance date in
+   `vault/handoff/custody-transfer.yaml`.
+4. Scheduled execution and access references are changed to the receiving path.
+5. Only then may this supplier copy be reduced to a non-confidential pointer or
+   removed in a separately reviewed, recoverable change.
+
+Until acceptance, do not add new sensitive operational evidence here unless it
+is necessary to maintain the active engagement. Do not claim that a handoff
+pack created inside this repository has itself transferred custody.

engagements/pilots/eng-coulomb-railiance01-ho-001/ENGAGEMENT.yaml

@@ -26,6 +26,15 @@ spec:
   vault:
     root: vault/
     memory: vault/memory.md
+    custody:
+      owner: coulomb
+      classification: client_confidential
+      current_repo: kaizen-agentic
+      current_state: transitional_supplier_custody
+      target_repo: railiance-infra
+      target_path: docs/evidence/resource-hosteurope-railiance01/engagements/eng-coulomb-railiance01-ho-001/
+      transfer_status: proposed
+      transfer_manifest: vault/handoff/custody-transfer.yaml
   schedule:
     path: schedule.yml
   checklists:

engagements/pilots/eng-coulomb-railiance01-ho-001/commercial/ledger.jsonl

@@ -3,3 +3,5 @@
 {"access_surcharge_product": "host_observe", "account": "coulomb-ops-kai", "amount_kai": 4900, "apiVersion": "kaizen.agentic/v1", "capability_tier": 4, "created_at": "2026-07-16T10:42:51Z", "currency": "KAI", "engagement_id": "eng-coulomb-railiance01-ho-001", "id": "kai-20260716T104251Z-deep_assessment", "kind": "KaiLedgerEntry", "metadata": {"access_class": "host_observe", "phase": "operating", "success": true, "target": "railiance01"}, "product": "deep_assessment", "session_ref": "reports/2026-07-16-deep-assessment.md", "type": "duty_charge"}
 {"access_surcharge_product": "privileged_ops", "account": "coulomb-ops-kai", "amount_kai": 5200, "apiVersion": "kaizen.agentic/v1", "capability_tier": 4, "created_at": "2026-07-16T11:05:17Z", "currency": "KAI", "engagement_id": "eng-coulomb-railiance01-ho-001", "id": "kai-20260716T110517Z-deep_assessment", "kind": "KaiLedgerEntry", "metadata": {"access_class": "privileged_ops", "phase": "operating", "success": true, "target": "railiance01"}, "product": "deep_assessment", "session_ref": "reports/2026-07-16-deep-assessment.md", "type": "duty_charge"}
 {"access_surcharge_product": "host_observe", "account": "coulomb-ops-kai", "amount_kai": 1700, "apiVersion": "kaizen.agentic/v1", "capability_tier": 4, "created_at": "2026-07-16T12:33:33Z", "currency": "KAI", "engagement_id": "eng-coulomb-railiance01-ho-001", "id": "kai-20260716T123333Z-standard_review", "kind": "KaiLedgerEntry", "metadata": {"access_class": "host_observe", "phase": "operating", "success": true, "target": "railiance01"}, "product": "standard_review", "session_ref": "reports/2026-07-16-standard-review.md", "type": "duty_charge"}
+{"access_surcharge_product": "host_observe", "account": "coulomb-ops-kai", "amount_kai": 500, "apiVersion": "kaizen.agentic/v1", "capability_tier": 4, "created_at": "2026-07-21T02:14:41Z", "currency": "KAI", "engagement_id": "eng-coulomb-railiance01-ho-001", "id": "kai-20260721T021441Z-short_assist", "kind": "KaiLedgerEntry", "metadata": {"access_class": "host_observe", "phase": "operating", "success": true, "target": "railiance01"}, "product": "short_assist", "session_ref": "reports/2026-07-21-short-assist.md", "type": "duty_charge"}
+{"access_surcharge_product": "privileged_ops", "account": "coulomb-ops-kai", "amount_kai": 800, "apiVersion": "kaizen.agentic/v1", "capability_tier": 4, "created_at": "2026-07-21T22:37:48Z", "currency": "KAI", "engagement_id": "eng-coulomb-railiance01-ho-001", "id": "kai-20260721T223748Z-short_assist", "kind": "KaiLedgerEntry", "metadata": {"access_class": "privileged_ops", "phase": "operating", "success": true, "target": "railiance01"}, "product": "short_assist", "session_ref": "reports/2026-07-22-short-assist.md", "type": "duty_charge"}

engagements/pilots/eng-coulomb-railiance01-ho-001/reports/2026-07-21-capacity-recheck-after-reboot.md

@@ -0,0 +1,24 @@
+# Capacity recheck after reboot — railiance01 — 2026-07-21
+
+**Action:** soft reboot via `sudo reboot` (to pick up provider resize if already assigned)
+**Reboot issued:** 2026-07-21 ~22:35 UTC
+**SSH back:** ~22:37 UTC
+
+## Result: still 2 vCPU / ~3.8 GiB after reboot
+
+| Resource | Target | After reboot |
+|----------|--------|--------------|
+| vCPU | 4 | **2** |
+| RAM | 16 GiB | **~3.8 GiB** |
+| Uptime | — | minutes after reboot |
+
+A guest reboot alone **did not** activate 4/16. The new flavor is almost certainly
+**not yet assigned** to this instance in OpenStack/HostEurope, or resize needs a
+**hard reboot / confirm** from the provider panel.
+
+## Next steps (provider)
+
+1. Panel: instance for **92.205.62.239** → flavor must show **4 vCPU / 16 GiB**
+2. Complete VERIFY_RESIZE / confirm if pending
+3. Prefer **hard reboot** from the panel if soft reboot already done
+4. Re-verify: `ssh railiance01 'nproc; free -h'`

engagements/pilots/eng-coulomb-railiance01-ho-001/reports/2026-07-21-capacity-recheck.md

@@ -0,0 +1,35 @@
+# Capacity recheck — railiance01 — 2026-07-21
+
+**Engagement:** eng-coulomb-railiance01-ho-001
+**Operator report (2026-07-16):** VM upgraded to 4 vCPU / 16 GiB RAM
+**Agent verify:** `ssh railiance01` at 2026-07-21 02:14 UTC
+
+## Result: still not visible in the guest OS
+
+| Resource | Operator target | Live guest |
+|----------|-----------------|------------|
+| vCPU | 4 | **2** |
+| RAM | 16 GiB | **~3.8 GiB** (MemTotal 4009884 kB) |
+| Swap | our /swapfile | 4 GiB, **~1.1 GiB used** |
+| Uptime | — | **4 days 13h** (no recent resize reboot) |
+| Hypervisor | — | KVM / OpenStack Nova |
+| k3s node | — | **Ready** |
+
+## Health snapshot
+
+| Metric | Value | Note |
+|--------|-------|------|
+| Load 1/5/15 | ~1.6 / 3.2 / 4.0 | Elevated vs 2 cores |
+| MemAvailable | ~571 Mi | Tight |
+| PSI memory full avg60 | ~6% | Pressure present |
+| Disk / | 57% of 96G | OK |
+| Top RSS | k3s, gitea, state-hub uvicorn | Same stack |
+
+## Conclusion
+
+The **4/16 flavor is still not applied** (or not applied to this instance). Capacity risk from the original pilot **remains open**. Confirm flavor on **92.205.62.239** in the provider panel and complete any VERIFY_RESIZE / hard reboot.
+
+```bash
+ssh railiance01 'nproc; free -h'
+# success criterion: nproc=4 and Mem ~15–16Gi
+```

engagements/pilots/eng-coulomb-railiance01-ho-001/reports/2026-07-21-short-assist.md

@@ -0,0 +1,13 @@
+# Session report — eng-coulomb-railiance01-ho-001
+
+- **Date:** 2026-07-21
+- **Duty:** short_assist
+- **Targets:** railiance01
+- **Outcome:** success
+- **Phase:** operating
+
+## Summary
+
+Capacity recheck 2026-07-21: guest still 2CPU/3.8G not 4/16; k3s Ready; swap 1.1G used
+
+_Billing metadata only in commercial/ledger.jsonl; no secrets in this report._

engagements/pilots/eng-coulomb-railiance01-ho-001/reports/2026-07-22-short-assist.md

@@ -0,0 +1,13 @@
+# Session report — eng-coulomb-railiance01-ho-001
+
+- **Date:** 2026-07-22
+- **Duty:** short_assist
+- **Targets:** railiance01
+- **Outcome:** success
+- **Phase:** operating
+
+## Summary
+
+Reboot completed; guest still 2CPU/3.8G not 4/16; resize must be finished in provider panel
+
+_Billing metadata only in commercial/ledger.jsonl; no secrets in this report._

engagements/pilots/eng-coulomb-railiance01-ho-001/schedule.yml

@@ -1,5 +1,6 @@
 # Duty cadence for eng-coulomb-railiance01-ho-001
-# activity-core wiring optional (Phase 3); manual prepare is enough for Phase 1
+# Entries declare intent. Manual prepare remains active until an engagement-specific
+# activity-core definition and versioned Glas profile are registered and smoke-tested.
 engagement_id: eng-coulomb-railiance01-ho-001
 timezone: Europe/Berlin
 entries:
@@ -12,7 +13,7 @@ entries:
     cadence: daily
     cron: "0 9 * * 1-5"
     enabled: true
-    notes: "Enabled after T10 ramp-up exit 2026-07-16; manual prepare until activity-core wired"
+    notes: "Declared after T10 ramp-up exit 2026-07-16; manual prepare until activity-core/Glas wiring is accepted"
 
   - id: weekly-os-security
     agent: host-operator
@@ -22,4 +23,4 @@ entries:
     cadence: weekly
     cron: "0 10 * * 1"
     enabled: true
-    notes: "Privileged upgrades remain human-gated even when enabled"
+    notes: "Privileged upgrades remain human-gated under manual or automated execution"

engagements/pilots/eng-coulomb-railiance01-ho-001/vault/handoff/README.md

@@ -1,6 +1,7 @@
 # Handoff pack — eng-coulomb-railiance01-ho-001
 
-Filled during **ramp-down** (RD-02).
+Prepared during **ramp-down** (RD-02). The custody target was selected on
+2026-08-20, but the receiving repository has not yet accepted the transfer.
 
 ## Contents (when complete)
 
@@ -10,4 +11,18 @@ Filled during **ramp-down** (RD-02).
 - Deferred patches and reboot debt
 - Contacts and access revocation status
 
-_Status: not started (engagement not in ramp_down)._
+## Custody
+
+- Owner: `coulomb`
+- Classification: `client_confidential`
+- Current location: transitional supplier custody in `kaizen-agentic`
+- Receiving authority: `railiance-infra`
+- Proposed path:
+  `docs/evidence/resource-hosteurope-railiance01/engagements/eng-coulomb-railiance01-ho-001/`
+- Transfer record: `custody-transfer.yaml`
+
+The complete engagement tree, rather than only this handoff directory, must be
+transferred because metrics, reports, approvals, and commercial metadata are
+all client records. The source is retained until explicit receiver acceptance.
+
+_Status: handoff target selected; transfer proposed; engagement still operating._

engagements/pilots/eng-coulomb-railiance01-ho-001/vault/handoff/custody-transfer.yaml

@@ -0,0 +1,27 @@
+apiVersion: kaizen.agentic/v1
+kind: EngagementCustodyTransfer
+metadata:
+  engagement_id: eng-coulomb-railiance01-ho-001
+  prepared: '2026-08-20'
+spec:
+  owner: coulomb
+  classification: client_confidential
+  source:
+    repo: kaizen-agentic
+    path: engagements/pilots/eng-coulomb-railiance01-ho-001/
+    custody: transitional_supplier
+  destination:
+    repo: railiance-infra
+    path: docs/evidence/resource-hosteurope-railiance01/engagements/eng-coulomb-railiance01-ho-001/
+    reason: canonical S1 authority for Railiance01 host-operational evidence
+  transfer_scope: complete_engagement_tree
+  exclusions:
+  - roles/host-operator/
+  acceptance:
+    status: proposed
+    accepted_commit: null
+    accepted_by: null
+    accepted_at: null
+  source_disposition:
+    status: retained_until_acceptance
+    action_after_acceptance: replace_with_non_confidential_pointer_after_review

engagements/pilots/eng-coulomb-railiance01-ho-001/vault/memory.md

@@ -2,8 +2,8 @@
 agent: host-operator
 engagement_id: eng-coulomb-railiance01-ho-001
 project: coulomb-railiance01
-last_updated: '2026-07-16'
-session_count: 5
+last_updated: '2026-07-22'
+session_count: 7
 confidentiality: client_owned
 ---
 
@@ -115,3 +115,6 @@ See reports/2026-07-16-capacity-upgrade-check.md
 - 2026-07-16 · railiance01 · deep_assessment · Approved P1-P4 done: 4G swap, journal vacuum, apt upgrade, UFW k3s API allowlist; k3s Ready; RAM still tight · ok
 - 2026-07-16 · railiance01 · capacity check after operator 4CPU/16G report: guest still 2/3.8G · watch
 - 2026-07-16 · railiance01 · standard_review · Operator reported 4CPU/16G upgrade; live guest still 2CPU/3.8G after reboot; k3s Ready; load calmer · ok
+- 2026-07-21 · railiance01 · capacity recheck: guest still 2CPU/3.8G (not 4/16); swap 1.1G used · watch
+- 2026-07-21 · railiance01 · short_assist · Capacity recheck 2026-07-21: guest still 2CPU/3.8G not 4/16; k3s Ready; swap 1.1G used · ok
+- 2026-07-22 · railiance01 · short_assist · Reboot completed; guest still 2CPU/3.8G not 4/16; resize must be finished in provider panel · ok

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

@@ -81,7 +81,7 @@ INTENT says repo should not own all concrete agent implementations; 21 agents li
 ## Related Artifacts
 
 - `SCOPE.md` — updated 2026-06-16
-- `workplans/kaizen-agentic-WP-0003-measurement-loop.md`
+- `workplans/KAIZEN-WP-0003-measurement-loop.md`
 - `history/2026-06-16-ecosystem-assessment.md`
 - `wiki/EcosystemIntegration.md`
 - `docs/adr/ADR-004-project-metrics-convention.md`

pyproject.toml

@@ -56,9 +56,9 @@ test = [
 kaizen-agentic = "kaizen_agentic.cli:safe_cli_wrapper"
 
 [project.urls]
-"Homepage" = "https://github.com/kaizen-agentic/kaizen-agentic"
-"Bug Reports" = "https://github.com/kaizen-agentic/kaizen-agentic/issues"
-"Source" = "https://github.com/kaizen-agentic/kaizen-agentic"
+"Homepage" = "https://forgejo.coulomb.social/coulomb/kaizen-agentic"
+"Bug Reports" = "https://forgejo.coulomb.social/coulomb/kaizen-agentic/issues"
+"Source" = "https://forgejo.coulomb.social/coulomb/kaizen-agentic"
 
 [tool.setuptools.packages.find]
 where = ["src"]

registry/capabilities/capability.agents.kaizen-framework.md

@@ -1,8 +1,8 @@
 ---
 id: capability.agents.kaizen-framework
 name: Kaizen Agentic Framework
-summary: AI agency framework providing 18 specialized deployable agent instruction sets plus persistent,
-  project-scoped memory and cross-agent coordination via a Coach meta-agent.
+summary: AI agency framework providing 20 deployable agent instruction sets, project memory,
+  metrics, role and engagement contracts, and scheduled preparation for governed execution.
 owner: kaizen-agentic
 status: draft
 domain: agents
@@ -10,13 +10,16 @@ tags:
 - agents
 - memory
 - coordination
+- metrics
+- scheduling
+- engagements
 maturity:
   discovery:
     current: D3
     target: D5
     confidence: medium
-    rationale: README documents the agent library, the agency framework (persistent memory, Coach meta-agent
-      synthesising fleet-wide patterns), and a versioned release (v1.4.0); has .gitea/workflows CI.
+    rationale: README, SCOPE, ADRs, and integration contracts document the agent library, memory,
+      metrics, scheduling, role and engagement surfaces, and versioned release v1.4.0; CI is present.
   availability:
     current: A2
     target: A3
@@ -29,9 +32,12 @@ external_evidence:
     confidence: low
     basis: scope_vs_intent_and_consumer_expectations
     satisfied_expectations:
-    - 18 specialized agent instruction sets
+    - 20 specialized agent instruction sets
     - persistent project-scoped agent memory
     - Coach meta-agent for fleet-wide pattern synthesis
+    - project metrics and optimizer workflow
+    - role packages and file-backed client engagements
+    - schedule validation and offline execution-bundle preparation
     broken_expectations: []
     out_of_scope_expectations: []
   reliability:
@@ -39,14 +45,17 @@ external_evidence:
     confidence: low
     basis: consumer_quality_signals
     known_reliability_risks:
-    - no external reuse evidence yet outside the originating project
+    - downstream execution depends on activity-core, glas-harness, and selected-rein contracts outside this repository
 discovery:
-  intent: Let agents arrive in a project already informed and improve over time through persistent, project-scoped
-    memory and fleet-wide coordination via a Coach meta-agent.
+  intent: Let agents arrive informed, work within explicit roles and engagement boundaries,
+    and improve through project memory, execution evidence, and governed scheduling contracts.
   includes:
-  - 18 specialized agent instruction sets
+  - 20 specialized agent instruction sets
   - persistent memory and coordination framework
   - Coach meta-agent pattern synthesis
+  - project execution metrics and optimizer artifacts
+  - role packages and forward-deployed engagement lifecycle helpers
+  - repo-local schedule manifests and offline preparation bundles
   excludes:
   - the underlying LLM inference itself (agents are instruction sets, not a model)
   assumptions: []
@@ -57,11 +66,13 @@ availability:
   target_level: A3
   current_artifacts:
   - Python package (`kaizen-agentic`) v1.4.0
-  - CLI (`agents-install-cli`)
+  - CLI (`kaizen-agentic`)
+  - versioned role, engagement, metrics, protocol, and schedule contracts
   target_artifacts: []
   consumption_modes:
   - cli
   - library import
+  - file contracts
 relations:
   depends_on: []
   supports: []
@@ -71,17 +82,19 @@ evidence:
   - README.md
   tests:
   - tests/
-  - .gitea/workflows/
+  - .forgejo/workflows/
   consumer_feedback: []
   bug_reports: []
   incidents: []
 consumer_guidance:
   recommended_for:
   - projects wanting a deployable, memory-persistent agent fleet with cross-agent coordination
+  - governed runtimes needing offline agent orientation and schedule preparation contracts
   not_recommended_for:
   - needs for a single stateless agent (framework overhead not justified)
   known_limitations:
-  - no cross-project reuse evidence recorded yet
+  - this package prepares work but does not schedule, authorize, or invoke an LLM
+  - production reliability telemetry is not yet sufficient for a higher reliability rating
 promotion_history: []
 ---
 
@@ -89,13 +102,13 @@ promotion_history: []
 
 ## Overview
 
-`kaizen-agentic` is an AI agency framework: 18 specialized agents deployable into any project, each gaining persistent project-scoped memory and coordination through a Coach meta-agent that synthesises fleet-wide patterns and briefs incoming agents.
+`kaizen-agentic` is an AI agency framework: 20 specialized agents deployable into any project, each gaining persistent project-scoped memory and coordination through a Coach meta-agent that synthesises fleet-wide patterns and briefs incoming agents.
 
 ## Assessment notes
 
 ### Discovery
 
-README documents the agent library, the agency framework (persistent memory, Coach meta-agent synthesising fleet-wide patterns), and a versioned release (v1.4.0); has .gitea/workflows CI.
+README documents the agent library, the agency framework (persistent memory, Coach meta-agent synthesising fleet-wide patterns), and a versioned release (v1.4.0); has .forgejo/workflows CI.
 
 ### Availability
 

registry/indexes/capabilities.yaml

@@ -1,11 +1,11 @@
 version: 1
-updated: '2026-07-06'
-domain: helix_forge
+updated: '2026-08-20'
+domain: agents
 capabilities:
 - id: capability.agents.kaizen-framework
   name: Kaizen Agentic Framework
-  summary: AI agency framework providing 18 specialized deployable agent instruction sets plus persistent,
-    project-scoped memory and cross-agent coordination via a Coach meta-agent.
+  summary: AI agency framework providing 20 deployable agent instruction sets, project memory,
+    metrics, role and engagement contracts, and scheduled preparation for governed execution.
   vector: D3 / A2 / C1 / R0
   domain: agents
   status: draft
@@ -15,6 +15,10 @@ capabilities:
   - agents
   - memory
   - coordination
+  - metrics
+  - scheduling
+  - engagements
   consumption_modes:
   - cli
   - library import
+  - file contracts

src/kaizen_agentic/cli.py

@@ -172,14 +172,14 @@ def safe_cli_wrapper():
 
 
 _FEEDBACK_CHANNELS = {
-    "issues": "https://gitea.coulomb.social/coulomb/kaizen-agentic/issues",
-    "issue_templates": "https://gitea.coulomb.social/coulomb/kaizen-agentic/issues/new/choose",
+    "issues": "https://forgejo.coulomb.social/coulomb/kaizen-agentic/issues",
+    "issue_templates": "https://forgejo.coulomb.social/coulomb/kaizen-agentic/issues/new/choose",
     "feedback_guide": (
-        "https://gitea.coulomb.social/coulomb/kaizen-agentic/"
+        "https://forgejo.coulomb.social/coulomb/kaizen-agentic/"
         "src/branch/main/docs/FEEDBACK.md"
     ),
     "contributing": (
-        "https://gitea.coulomb.social/coulomb/kaizen-agentic/"
+        "https://forgejo.coulomb.social/coulomb/kaizen-agentic/"
         "src/branch/main/CONTRIBUTING.md"
     ),
 }
@@ -200,7 +200,7 @@ def feedback(as_json: bool):
         "channels": _FEEDBACK_CHANNELS,
         "templates": ["bug_report", "feature_request", "feedback"],
         "cli_hint": (
-            "Use Gitea issue templates or State Hub messages "
+            "Use Forgejo issue templates or State Hub messages "
             "for cross-repo coordination"
         ),
     }

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

@@ -18,7 +18,7 @@ You are the Contributing Keeper, a specialized agent focused on maintaining CONT
 2. **Welcoming Onboarding**: Provide friendly, accessible instructions that lower the barrier to entry for new contributors
 3. **Quality Standards**: Set clear expectations for code style, testing, and documentation aligned with PythonVibes standards
 4. **Workflow Documentation**: Define contribution types, development setup, and submission processes
-5. **Agent Integration**: Seamlessly integrate the 17+ specialized agents and Kaizen philosophy into contribution workflows
+5. **Agent Integration**: Seamlessly integrate the 20 specialized agents and Kaizen philosophy into contribution workflows
 6. **Community Building**: Foster a professional tone and maintain behavioral expectations
 
 ### Authority and Scope
@@ -30,7 +30,7 @@ You have explicit authority to:
 - Establish welcoming, friendly tone that encourages participation rather than intimidating newcomers
 - Define clear development setup instructions with proper virtual environment and dependency management
 - Create issue reporting guidelines and pull request submission workflows
-- Integrate the 17+ specialized agents naturally into contribution processes
+- Integrate the 20 specialized agents naturally into contribution processes
 - Reference the comprehensive Makefile commands and testing infrastructure
 - Maintain focus on reducing maintainer burden while improving contribution quality
 - Avoid antipatterns: outdated information, overly demanding processes, unwelcoming tone, lack of templates
@@ -161,7 +161,7 @@ When reporting bugs, please include:
 
 ## Agent-Assisted Development
 
-This repository includes 17+ specialized agents to assist with development:
+This repository includes 20 specialized agents to assist with development:
 - Use `todo-keeper` for TODO.md maintenance
 - Use `changelog-keeper` for CHANGELOG.md updates
 - Use `contributing-keeper` for this file maintenance

src/kaizen_agentic/data/agents/agent-project-assistant.md

@@ -21,12 +21,12 @@ You are the MarkiTect project assistant, specialized in providing project status
 - **roadmap/**: Directory with current and close range roadmap-topic-directories for concepts, workplans, examples...
 - **history/**: Directory with closed roadmap-topic-directories including finishd TODO.md files as YYMMDD-DONE.md
 - **Makefile**: Provides helpers to use and improve the capabilities provided by the project
-  **Gitea Issues**: Backlog of issues and backlog of tasks stored as issues in gitea before selection as roadmap topics
+  **Forgejo Issues**: Backlog of issues and tasks stored as issues in Forgejo before selection as roadmap topics
 
 ### Project Infrastructure Knowledge
 
 **Repository Structure:**
-- Main project hosted on Gitea with issue tracking for use cases and tasks
+- Main project hosted on Forgejo 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/
@@ -36,7 +36,7 @@ You are the MarkiTect project assistant, specialized in providing project status
 Important: Respect the directory structure! If in doubt ask or use directories under tmp/ to keep the structure clean!
 
 **Development Workflow:**
-- Issue-driven development using Gitea API integration
+- Issue-driven development using Forgejo API integration
 - Issue management via universal issue-facade CLI that works with multiple backends
 - All commits require green test state
 
@@ -48,8 +48,8 @@ Important: Respect the directory structure! If in doubt ask or use directories u
 - **Discovery Tools**: `make capability-search TERM=xyz` to find existing functionality
 
 **Issue Management Protocol:**
-- **Gitea-First**: Feature requests, bugs, and enhancements should be documented as Gitea issues
-- **Issue Creation**: When new requirements emerge, create issues in Gitea immediately but do NOT implement immediately
+- **Forgejo-First**: Feature requests, bugs, and enhancements should be documented as Forgejo issues
+- **Issue Creation**: When new requirements emerge, create issues in Forgejo immediately but do NOT implement immediately
 - **Strategic Planning**: Issues should be prioritized and scheduled based on project roadmap (history/ROADMAP.md)
 - **Implementation Discipline**: Only work on issues that are explicitly planned for the current session
 - **Issue Workflow**: Create → Triage → Plan → Schedule → Implement → Close
@@ -67,12 +67,12 @@ When asked about project status or next steps:
 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
-5. **Planning New Stuff**: Requirements (Epics and Stories) are gitea issues to be planned as roadmap topics
+5. **Planning New Stuff**: Requirements (Epics and Stories) are Forgejo issues to be planned as roadmap topics
 6. **Consider Git Status**: Allways be aware of current working directory state and recent commits
 
 ### Issue Management Guidelines
 
-**When to Create Gitea Issues:**
+**When to Create Forgejo Issues:**
 - New feature requests or enhancement ideas emerge during development
 - Bugs or technical debt are discovered but not immediately fixable
 - Future improvements are identified but outside current session and topic scope

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

@@ -21,7 +21,7 @@ You are a specialized release management agent focused on Python package publica
 - **Package Building**: Build distribution packages (sdist and wheel) using modern Python tools
 - **Quality Assurance**: Run comprehensive tests and validation before publication
 - **PyPI Publication**: Handle TestPyPI and production PyPI uploads with proper authentication
-- **Post-Release Tasks**: Update documentation, create GitHub releases, and notify stakeholders
+- **Post-Release Tasks**: Update documentation, create Forgejo releases, and notify stakeholders
 
 ### Documentation Updates
 - **Installation Instructions**: Update installation guides to reflect publication status
@@ -39,7 +39,7 @@ You are a specialized release management agent focused on Python package publica
 ### Production Release
 - Full validation and testing required
 - Publish to production PyPI
-- Create GitHub releases with assets
+- Create Forgejo releases with assets
 - Update all documentation
 
 ### Patch Releases
@@ -55,7 +55,7 @@ Provide these release- prefixed make targets:
 - `release-prepare`: Prepare release (update versions, build packages)
 - `release-test`: Test publication workflow using TestPyPI
 - `release-publish`: Publish to production PyPI
-- `release-finalize`: Post-release tasks (tags, GitHub release, documentation)
+- `release-finalize`: Post-release tasks (tags, Forgejo release, documentation)
 - `release-rollback`: Emergency rollback procedures
 
 ## Best Practices
@@ -83,7 +83,7 @@ Provide these release- prefixed make targets:
 ## Integration Points
 
 ### CI/CD Systems
-- GitHub Actions workflow integration
+- Forgejo Actions workflow integration
 - Automated testing on multiple Python versions
 - Security scanning and dependency checking
 - Automated documentation deployment

src/kaizen_agentic/data/agents/agent-tdd-workflow.md

@@ -123,7 +123,7 @@ You are the authoritative guide for the TDD8 workflow using the tddai system. Yo
 **Supporting Commands:**
 - `make test-coverage NUM=X` - Analyze test coverage for an issue
 - `make test` - Run all tests
-- `make list-issues` - Show all Gitea issues with status
+- `make list-issues` - Show all Forgejo issues with status
 - `make show-issue NUM=X` - Show detailed view of specific issue
 
 ### Workspace Management Understanding
@@ -306,7 +306,7 @@ Extend data access layer with search methods. Consider adding full-text search f
 - **Issue Tracker Integration:** Compatible with Gitea, GitHub, and similar platforms
 - **Issue Reading:** Use `IssueFetcher` for programmatic access
 - **Issue Writing:** Use `IssueWriter` for updates via authenticated PATCH
-- **Environment Variables:** `GITEA_API_TOKEN` or platform-specific tokens for authentication
+- **Environment Variables:** `FORGEJO_API_TOKEN` or platform-specific tokens for authentication
 
 ### Test Framework
 - **pytest-based:** All tests use pytest framework

src/kaizen_agentic/data/agents/agent-test-maintenance.md

@@ -86,7 +86,7 @@ Remove tests when:
 - Update tests to reflect new command structures and access patterns
 
 ### Backend Systems
-- **Primary**: Gitea backend for issue management
+- **Primary**: Forgejo backend for issue management
 - **Secondary**: Local plugin for offline/alternative workflows
 - **Focus**: Prioritize tests for actively used functionality
 
@@ -122,7 +122,7 @@ ACTION: Modify assertions to match new CLI structure
 ### Scenario 2: Obsolete Functionality
 ```
 FAILING: test_local_plugin_sequential_numbering()
-CAUSE: Local plugin not actively used, Gitea is primary backend
+CAUSE: Local plugin not actively used, Forgejo is primary backend
 DECISION: Remove test as functionality is not essential to current workflow
 ACTION: Remove test method and document rationale
 ```

src/kaizen_agentic/registry.py

@@ -85,10 +85,16 @@ class AgentDefinition:
             if key in frontmatter:
                 deps = frontmatter[key]
                 if isinstance(deps, list):
-                    dependencies.update(deps)
+                    dependencies.update(
+                        dep.strip()
+                        for dep in deps
+                        if isinstance(dep, str) and dep.strip()
+                    )
                 elif isinstance(deps, str):
                     # Handle comma-separated string
-                    dependencies.update([d.strip() for d in deps.split(",")])
+                    dependencies.update(
+                        dep.strip() for dep in deps.split(",") if dep.strip()
+                    )
 
         # Look for explicit dependencies in content
         dep_patterns = [
@@ -101,7 +107,11 @@ class AgentDefinition:
             matches = re.findall(pattern, content, re.IGNORECASE)
             for match in matches:
                 if isinstance(match, str):
-                    deps = [d.strip().strip("\"'") for d in match.split(",")]
+                    deps = [
+                        dependency
+                        for dep in match.split(",")
+                        if (dependency := dep.strip().strip("\"'"))
+                    ]
                     dependencies.update(deps)
 
         # Look for specific agent references in content (more precise)

tests/test_cli_error_handling.py

@@ -222,7 +222,7 @@ class TestWorkaroundRemovalReadiness:
         # Test that the CLI works when invoked as a subprocess
         result = subprocess.run(
             [
-                "python",
+                sys.executable,
                 "-c",
                 'from kaizen_agentic.cli import safe_cli_wrapper; import sys; sys.argv = ["kaizen-agentic", "list"]; safe_cli_wrapper()',
             ],

tests/test_feedback_cli.py

@@ -14,7 +14,7 @@ def test_feedback_human_output():
     result = runner.invoke(cli, ["feedback"])
     assert result.exit_code == 0
     assert "feedback channels" in result.output.lower()
-    assert "gitea.coulomb.social" in result.output
+    assert "forgejo.coulomb.social" in result.output
     assert "bug report" in result.output.lower()
 
 

tests/test_registry.py

@@ -58,6 +58,25 @@ description: Second test agent
     assert registry.get_agent("agent-two") is not None
 
 
+def test_agent_definition_ignores_empty_dependencies(tmp_path):
+    """An empty dependency declaration must not create an empty-name edge."""
+    agent_content = """---
+name: standalone-agent
+description: Agent with an explicit empty dependency list
+dependencies: []
+---
+
+# Standalone Agent
+"""
+
+    agent_file = tmp_path / "agent-standalone-agent.md"
+    agent_file.write_text(agent_content)
+
+    agent_def = AgentDefinition.from_file(agent_file)
+
+    assert agent_def.dependencies == set()
+
+
 def test_agent_registry_get_agent(tmp_path):
     """Test getting specific agent."""
     agent_content = """---

wiki/EcosystemIntegration.md

@@ -178,9 +178,11 @@ beyond CLI context assembly. Token metrics align with wiki pricing tiers.
 Register kaizen-agentic and agent categories with primary/secondary domain
 bindings when capability catalog matures.
 
-### identity-canon (P3)
+### InfoTechCanon identity model (P3)
 
-Terminology for agent persona vs deployed instance vs session actor —
+The [identity model](../../info-tech-canon/infospace/models/identity/InfoTechCanonIdentityModel.md)
+and [organization model](../../info-tech-canon/infospace/models/organization/InfoTechCanonOrganizationModel.md)
+provide terminology for agent persona vs deployed instance vs session actor —
 supports "digital talent agency" framing without overloading "user".
 
 ### tele-mcp (TBD)
@@ -209,7 +211,7 @@ WP-0001 T04. Assess before depending on it.
 2. `wiki/EcosystemIntegration.md` — this document
 3. `docs/adr/ADR-004-project-metrics-convention.md` — project metrics schema
 4. `history/2026-06-16-ecosystem-assessment.md` — full repo comparison
-5. `workplans/kaizen-agentic-WP-0004-ecosystem-integration.md` — implementation plan
+5. `workplans/KAIZEN-WP-0004-ecosystem-integration.md` — implementation plan
 
 ---
 

workplans/ADHOC-2026-08-21.md

@@ -0,0 +1,29 @@
+---
+id: KAIZEN-WP-ADHOC-2026-08-21
+type: workplan
+title: "Ad hoc Glas execution-boundary alignment"
+domain: agents
+repo: kaizen-agentic
+status: finished
+owner: codex
+topic_slug: glas-execution-boundary-alignment
+created: "2026-08-21"
+updated: "2026-08-21"
+state_hub_workstream_id: "82fcbb9f-1b9f-5809-93eb-b65eea1d985f"
+---
+
+# Ad hoc Glas execution-boundary alignment
+
+## Align the documented execution handoff with Glas contract 1.0
+
+```task
+id: KAIZEN-WP-ADHOC-2026-08-21-T01
+status: done
+priority: high
+```
+
+
+Apply the completed GLAS-WP-0004 handoff: Kaizen blueprints and agent instances
+name a versioned `harness_profile_ref`; Glas resolves the concrete rein, model,
+sandbox, tool policy, and limits. Preserve activity-core scheduling and durable
+work ownership and rein-local task intake where it already exists.

workplans/ADHOC-2026-09-06.md

@@ -0,0 +1,38 @@
+---
+id: KAIZEN-WP-ADHOC-2026-09-06
+type: workplan
+title: "Update live canon federation references"
+domain: agents
+repo: kaizen-agentic
+status: finished
+owner: codex
+created: "2026-09-06"
+updated: "2026-09-06"
+state_hub_workstream_id: "6f406e43-11e7-56bd-95cc-1530eb292791"
+---
+
+## Follow current canon source owners
+
+```task
+id: KAIZEN-WP-ADHOC-2026-09-06-T01
+status: done
+priority: medium
+state_hub_task_id: "bec020d8-5c7c-5aff-a78d-adf12f85aee6"
+```
+
+Bounded source-reference correction authorized by CFED-WP-0001-T09. Preserve
+historical workplans, evidence, UUIDs, runtime contracts and capability IDs.
+Identity/evidence meanings now reference InfoTechCanon; the same renamed
+repository is CommerceCanon for commercial semantics.
+
+Files reviewed:
+
+- `wiki/EcosystemIntegration.md`
+
+Acceptance: no live obsolete source reference in these files, valid YAML/Python
+where applicable, unchanged runtime behavior, and consolidated fleet evidence in
+prj-canon-federation. This does not assert independent consumer adoption.
+
+Result: current source references corrected; syntax and targeted verification
+passed. Consolidated proof is owned by CFED-WP-0001-T09. No new implementation
+residual is introduced by this documentation/coordinate update.

workplans/KAIZEN-WP-0001-community-engagement.md

@@ -4,17 +4,18 @@ type: workplan
 title: "Community Engagement and Advanced Automation (v1.1.0)"
 domain: agents
 repo: kaizen-agentic
-status: completed
+status: finished
 owner: kaizen-agentic
 topic_slug: custodian
 state_hub_workstream_id: a43e92af-1cb4-4c55-8b74-19588e0ded20
 created: "2026-03-18"
 updated: "2026-06-18"
+state_hub_workstream_id: "a43e92af-1cb4-4c55-8b74-19588e0ded20"
 ---
 
 # KAIZEN-WP-0001 — Community Engagement and Advanced Automation
 
-**Status:** completed
+**Status:** finished
 **Owner:** kaizen-agentic
 **Repo:** kaizen-agentic
 **Target version:** 1.1.0

workplans/KAIZEN-WP-0002-agency-framework.md

@@ -4,17 +4,18 @@ type: workplan
 title: "Agency Framework: Project Memory, Coaching, and sys-medic Integration"
 domain: agents
 repo: kaizen-agentic
-status: done
+status: finished
 owner: kaizen-agentic
 topic_slug: custodian
 state_hub_workstream_id: d82b5ec9-ee3c-4b3b-9a27-2e30ab3a8158
 created: "2026-03-18"
 updated: "2026-03-19"
+state_hub_workstream_id: "d82b5ec9-ee3c-4b3b-9a27-2e30ab3a8158"
 ---
 
 # KAIZEN-WP-0002 — Agency Framework: Project Memory, Coaching, and sys-medic Integration
 
-**Status:** done
+**Status:** finished
 **Owner:** kaizen-agentic
 **Repo:** kaizen-agentic
 

workplans/KAIZEN-WP-0003-measurement-loop.md

@@ -4,7 +4,7 @@ type: workplan
 title: "Measurement Loop: Metrics Convention, Collection, and Optimizer Integration"
 domain: agents
 repo: kaizen-agentic
-status: completed
+status: finished
 owner: kaizen-agentic
 topic_slug: custodian
 state_hub_workstream_id: 36252a45-f360-4496-bf77-17b5dfb02767
@@ -107,11 +107,12 @@ tasks:
     title: CHANGELOG entry for metrics convention and CLI
     status: done
     state_hub_task_id: 748be9f3-f6ac-4f26-a844-6330268935b6
+state_hub_workstream_id: "36252a45-f360-4496-bf77-17b5dfb02767"
 ---
 
 # KAIZEN-WP-0003 — Measurement Loop: Metrics Convention, Collection, and Optimizer Integration
 
-**Status:** completed
+**Status:** finished
 **Owner:** kaizen-agentic
 **Repo:** kaizen-agentic
 **Target version:** 1.1.0 (partial; remainder in WP-0001)

workplans/KAIZEN-WP-0004-ecosystem-integration.md

@@ -4,7 +4,7 @@ type: workplan
 title: "Ecosystem Integration: Helix Forge, activity-core, and artifact-store"
 domain: agents
 repo: kaizen-agentic
-status: completed
+status: finished
 owner: kaizen-agentic
 topic_slug: custodian
 state_hub_workstream_id: 76be7294-e201-4074-91c0-6421992470fe
@@ -87,11 +87,12 @@ tasks:
     title: Update ecosystem assessment with Part 4 outcomes
     status: done
     state_hub_task_id: 2c1f66f5-e6ab-4e19-88ca-818acb15a706
+state_hub_workstream_id: "76be7294-e201-4074-91c0-6421992470fe"
 ---
 
 # KAIZEN-WP-0004 — Ecosystem Integration: Helix Forge, activity-core, and artifact-store
 
-**Status:** completed
+**Status:** finished
 **Owner:** kaizen-agentic
 **Repo:** kaizen-agentic
 **Depends on:** KAIZEN-WP-0003 Part 3 (metrics CLI + `metrics optimize` operational)

workplans/KAIZEN-WP-0005-adoption-parity.md

@@ -4,7 +4,7 @@ type: workplan
 title: "Adoption Polish and Fleet Parity (v1.2.0)"
 domain: agents
 repo: kaizen-agentic
-status: completed
+status: finished
 owner: kaizen-agentic
 topic_slug: custodian
 state_hub_workstream_id: 88c7b3e6-be98-480c-b47b-936e74a1a31b
@@ -75,11 +75,12 @@ tasks:
     title: Verify bidirectional Helix correlation doc link
     status: done
     state_hub_task_id: 37679ce7-dcb6-42a4-820d-cf8b32c2a248
+state_hub_workstream_id: "88c7b3e6-be98-480c-b47b-936e74a1a31b"
 ---
 
 # KAIZEN-WP-0005 — Adoption Polish and Fleet Parity
 
-**Status:** completed
+**Status:** finished
 **Owner:** kaizen-agentic
 **Repo:** kaizen-agentic
 **Target version:** 1.2.0

workplans/KAIZEN-WP-0006-scheduled-agent-execution.md

@@ -4,7 +4,7 @@ type: workplan
 title: "Scheduled Agent Execution via activity-core (v1.3.0)"
 domain: agents
 repo: kaizen-agentic
-status: done
+status: finished
 owner: kaizen-agentic
 topic_slug: custodian
 state_hub_workstream_id: d4edb92b-526f-4ee4-8efe-a9fa84ab6dff
@@ -85,11 +85,13 @@ tasks:
 - id: T18
   state_hub_task_id: 73986472-bf19-4b13-af1b-6505ab944459
   status: done
-  title: Update wiki/EcosystemIntegration.md and CHANGELOG for v1.3.0---
+  title: Update wiki/EcosystemIntegration.md and CHANGELOG for v1.3.0
+  state_hub_workstream_id: "d4edb92b-526f-4ee4-8efe-a9fa84ab6dff"
+---
 
 # KAIZEN-WP-0006 — Scheduled Agent Execution via activity-core
 
-**Status:** done
+**Status:** finished
 **Owner:** kaizen-agentic
 **Repo:** kaizen-agentic
 **Target version:** 1.3.0

workplans/KAIZEN-WP-0007-agent-authoring-doc-generation.md

@@ -4,7 +4,7 @@ type: workplan
 title: "Agent Authoring & Doc Generation (v1.4.0)"
 domain: agents
 repo: kaizen-agentic
-status: done
+status: finished
 owner: kaizen-agentic
 topic_slug: custodian
 state_hub_workstream_id: a8bc88a4-0ee3-44c6-aff5-9d7f54a316f5
@@ -36,11 +36,13 @@ tasks:
 - id: T06
   state_hub_task_id: 6715aa6f-1ee0-4f22-9249-f1cd41763cd1
   status: done
-  title: Docs, CLI cheat sheet, CHANGELOG for v1.4.0---
+  title: Docs, CLI cheat sheet, CHANGELOG for v1.4.0
+  state_hub_workstream_id: "a8bc88a4-0ee3-44c6-aff5-9d7f54a316f5"
+---
 
 # KAIZEN-WP-0007 — Agent Authoring & Doc Generation
 
-**Status:** done
+**Status:** finished
 **Owner:** kaizen-agentic
 **Repo:** kaizen-agentic
 **Target version:** 1.4.0

workplans/KAIZEN-WP-0008-coulomb-loop-supplier-engagement.md

@@ -4,7 +4,7 @@ type: workplan
 title: "Coulomb-loop supplier engagement (customer-repo playbook)"
 domain: agents
 repo: kaizen-agentic
-status: done
+status: finished
 owner: kaizen-agentic
 topic_slug: custodian
 customer_repo: coulomb-loop
@@ -49,7 +49,7 @@ state_hub_workstream_id: "80f473eb-d052-4f50-a633-806f03c469be"
 
 # KAIZEN-WP-0008 — Coulomb-loop Supplier Engagement
 
-**Status:** done
+**Status:** finished
 **Owner:** kaizen-agentic (supplier)
 **Customer:** `coulomb-loop` (coulomb_social domain)
 **Depends on:** WP-0006 (schedule contract), WP-0004 (activity-core integration)
@@ -98,7 +98,7 @@ Part 3 (T07–T08, T10)  ── after LOOP-WP-0004 supplier-notes available
 id: KAIZEN-WP-0008-T01
 status: done
 priority: high
-state_hub_task_id: "177bb16c-6239-43f2-8d99-f4498c31d74a"
+state_hub_task_id: "c63b4e59-3797-5b41-99d2-8d2bedd84977"
 ```
 
 Create `docs/integrations/customer-engagement-repo-layout.md` from coulomb-loop
@@ -122,7 +122,7 @@ No code — layout contract only.
 id: KAIZEN-WP-0008-T02
 status: done
 priority: high
-state_hub_task_id: "90bd0fc2-6e49-4a59-9a78-91e749cef8a6"
+state_hub_task_id: "03ca3db6-511b-5e49-93c1-f19d8df0c414"
 ```
 
 Add `docs/integrations/customer-engagement-playbook.md`:
@@ -142,7 +142,7 @@ Link to coulomb-loop as reference implementation.
 id: KAIZEN-WP-0008-T05
 status: done
 priority: high
-state_hub_task_id: "a48598b7-2a33-46ef-8594-6a2702459f39"
+state_hub_task_id: "33e8b258-dcbc-5144-8e97-258fbe69f985"
 ```
 
 Completed 2026-06-18 on kaizen-agentic, the-custodian, activity-core. Bootstrap
@@ -172,7 +172,7 @@ Record friction in coulomb-loop `loops/kaizen-stack/supplier-notes.md`.
 id: KAIZEN-WP-0008-T03
 status: done
 priority: medium
-state_hub_task_id: "26ee0f8d-2b69-4796-b276-b76238d67546"
+state_hub_task_id: "257bebed-8676-5c8d-a87d-100f07c29bd3"
 ```
 
 Emit NATS event `kaizen.metrics.recorded` when flag set:
@@ -190,7 +190,7 @@ Default: off (backward compatible).
 id: KAIZEN-WP-0008-T04
 status: done
 priority: medium
-state_hub_task_id: "62324bd2-1737-4864-889c-56179d0d11e8"
+state_hub_task_id: "cdfec704-a3ec-5045-88f2-1c758d6db2e7"
 ```
 
 Scaffold customer-target schedule with bootstrap crons:
@@ -208,7 +208,7 @@ Writes hourly crons per ADR-003; documents engagement slug in schedule comment.
 id: KAIZEN-WP-0008-T06
 status: done
 priority: medium
-state_hub_task_id: "5c06cdd9-655d-4837-b725-1f89b83db6d4"
+state_hub_task_id: "87f577e7-466c-50e5-831c-27f165e29029"
 ```
 
 `docs/adr/ADR-006-customer-engagement-convention.md` — formalize supplier/customer
@@ -220,7 +220,7 @@ split, `.kaizen/` placement in target repos, playbook lifecycle.
 id: KAIZEN-WP-0008-T09
 status: done
 priority: medium
-state_hub_task_id: "f45077ea-5d24-4a85-bac2-ab9a3f61c20b"
+state_hub_task_id: "fea67e82-11a9-5591-8045-62f2bb29efc6"
 ```
 
 Covered by `tests/test_metrics_emit_event.py` and `tests/test_schedule_cli.py`
@@ -236,7 +236,7 @@ Covered by `tests/test_metrics_emit_event.py` and `tests/test_schedule_cli.py`
 id: KAIZEN-WP-0008-T07
 status: done
 priority: low
-state_hub_task_id: "0ef49fb5-af2f-4adf-aa90-1ea2cf389d00"
+state_hub_task_id: "1b0c03dd-6072-5394-9c93-d6b827bc0e92"
 ```
 
 After LOOP-WP-0004 T07 draft in coulomb-loop, merge into playbook v1.
@@ -248,7 +248,7 @@ Target: second customer can copy template repo and run checklist in one session.
 id: KAIZEN-WP-0008-T08
 status: done
 priority: low
-state_hub_task_id: "c9bee570-89b5-43e5-aabc-23c7dcc4e30c"
+state_hub_task_id: "62d34189-0d7d-52e2-acc7-cf5aacf09fdd"
 ```
 
 Design-only (implements DEC-003 option C): YAML manifest mapping supplier
@@ -260,7 +260,7 @@ definition id → customer cron/labels/enabled overrides. No runtime in v1.
 id: KAIZEN-WP-0008-T10
 status: done
 priority: low
-state_hub_task_id: "052a592b-ae7c-4213-9e09-eb8b37119d5e"
+state_hub_task_id: "71323ad6-31b5-5252-b3ba-ccaf83e0f006"
 ```
 
 Update `wiki/EcosystemIntegration.md`, `CHANGELOG [Unreleased]`, cross-link

workplans/KAIZEN-WP-0009-forward-deployed-agency.md

@@ -47,7 +47,7 @@ tasks:
   - id: T11
     status: done
     title: Absorb pilot friction; ADR for engagement convention; docs cross-links
-state_hub_workstream_id: "70f7afb1-78f1-4e3b-8437-48840b5b58cc"
+state_hub_workstream_id: "9669eada-7f52-58a9-acfd-61a5bed026d1"
 ---
 
 # KAIZEN-WP-0009 — Forward-Deployed Agency
@@ -98,7 +98,7 @@ Client request → quote (Kai) → fund → staff Role → ramp-up → operate
 id: KAIZEN-WP-0009-T01
 status: done
 priority: high
-state_hub_task_id: "a9440a09-00fb-4668-94a7-f02ae14031d2"
+state_hub_task_id: "94cfd310-267b-5418-8dc1-541ba059135f"
 ```
 
 Delivered 2026-07-16:
@@ -113,7 +113,7 @@ Delivered 2026-07-16:
 id: KAIZEN-WP-0009-T02
 status: done
 priority: high
-state_hub_task_id: "d624072d-1939-40f0-bfa2-498a24673b4c"
+state_hub_task_id: "c4d4c6cf-d7c7-5da7-83a9-598811b7bef5"
 ```
 
 **Delivered 2026-07-16 (working defaults):**
@@ -127,7 +127,7 @@ Docs promoted to v0.2. Sponsor may override; ADR-007 deferred to T11.
 id: KAIZEN-WP-0009-T03
 status: done
 priority: high
-state_hub_task_id: "407eae88-a3fe-4da9-80eb-ea92828fd488"
+state_hub_task_id: "79c2c9d7-d24b-514a-94e8-7bdd307fd5eb"
 ```
 
 **Delivered:** `roles/host-operator/` — ROLE.yaml v0.1.0, agent-definition,
@@ -140,7 +140,7 @@ base_agent sys-medic, tier 4.
 id: KAIZEN-WP-0009-T04
 status: done
 priority: high
-state_hub_task_id: "c90fd780-982f-48ea-a017-2eee44f2e8c7"
+state_hub_task_id: "88c9f673-f4bd-5337-91a1-0e8757b90c5e"
 ```
 
 **Delivered:** `engagements/pilots/eng-coulomb-railiance01-ho-001/` full tree
@@ -152,7 +152,7 @@ state_hub_task_id: "c90fd780-982f-48ea-a017-2eee44f2e8c7"
 id: KAIZEN-WP-0009-T05
 status: done
 priority: high
-state_hub_task_id: "e48f0ec3-4258-4650-8c92-eb25e4dca755"
+state_hub_task_id: "8a09ea5e-7dd2-574d-9dd8-f949dbd342db"
 ```
 
 **Delivered:** `agent-host-operator.md` bound definition (targets, phase,
@@ -164,7 +164,7 @@ approval gates, vault path, charter, protocol table).
 id: KAIZEN-WP-0009-T06
 status: done
 priority: medium
-state_hub_task_id: "3c166660-b4b8-49fc-9dcb-c47e7d676792"
+state_hub_task_id: "d33c8f2a-81f6-59ef-89f0-b995d7e0c330"
 ```
 
 **Delivered:** Role checklists + pilot `checklists/ramp-up-status.md` and
@@ -176,7 +176,7 @@ state_hub_task_id: "3c166660-b4b8-49fc-9dcb-c47e7d676792"
 id: KAIZEN-WP-0009-T07
 status: done
 priority: medium
-state_hub_task_id: "16e90a62-973b-4cc8-ac36-87bfad52e538"
+state_hub_task_id: "eb5be2f8-6ca8-58aa-b822-976ffe369ac3"
 ```
 
 **Delivered:** `commercial/quote.yaml` (~72 800 Kai month-1), `ledger.jsonl`
@@ -188,7 +188,7 @@ with quote-open note, commercial README.
 id: KAIZEN-WP-0009-T08
 status: done
 priority: medium
-state_hub_task_id: "52f7d872-1087-4890-9439-8d6c704351fd"
+state_hub_task_id: "12512c73-e6c8-5c55-b90a-fc190ce7aca3"
 ```
 
 **Delivered:** `kaizen-agentic engagement` CLI group + `engagement.py` module:
@@ -204,7 +204,7 @@ Tests: `tests/test_engagement_cli.py`. Docs: CLI cheat sheet section.
 id: KAIZEN-WP-0009-T09
 status: done
 priority: medium
-state_hub_task_id: "82ac0b5a-0309-4912-93bf-f05bee2abbc2"
+state_hub_task_id: "466c9dcd-22e3-5a1b-878d-8cb8c06e48c2"
 ```
 
 **Delivered:** `engagement close-session` wires vault session log, engagement-scoped
@@ -218,7 +218,7 @@ points at close-session. Tests cover formula, scrub, and CLI.
 id: KAIZEN-WP-0009-T10
 status: done
 priority: high
-state_hub_task_id: "6b21da0d-7ba5-4c64-92cb-9237cf71a102"
+state_hub_task_id: "007b70ed-82a6-58c7-bbad-a152c980a8af"
 ```
 
 **Delivered 2026-07-16:** Live observe on railiance01 via `ssh railiance01`
@@ -233,7 +233,7 @@ deep_assessment close-session (4900 Kai). No privileged changes applied.
 id: KAIZEN-WP-0009-T11
 status: done
 priority: low
-state_hub_task_id: "f212949d-de22-46de-9ae0-63fc21e2701f"
+state_hub_task_id: "ff496c38-8964-572b-81b5-f72335810da6"
 ```
 
 **Delivered 2026-07-16:** ADR-007 accepted; forward-deployed engagement playbook
@@ -268,4 +268,4 @@ All tasks T01–T11 done. Workplan **finished** 2026-07-16.
 - [forward-deployed-engagement-architecture.md](../docs/forward-deployed-engagement-architecture.md)
 - [ADR-006](../docs/adr/ADR-006-customer-engagement-convention.md)
 - [agent-sys-medic.md](../agents/agent-sys-medic.md)
-- [KAIZEN-WP-0008](kaizen-agentic-WP-0008-coulomb-loop-supplier-engagement.md)
+- [KAIZEN-WP-0008](KAIZEN-WP-0008-coulomb-loop-supplier-engagement.md)

workplans/KAIZEN-WP-0010-forgejo-pypi-migration.md

@@ -0,0 +1,192 @@
+---
+id: KAIZEN-WP-0010
+type: workplan
+title: "Migrate package distribution from gitea to forgejo before CoulombCore retires"
+domain: agents
+repo: kaizen-agentic
+status: finished
+owner: kaizen-agentic
+topic_slug: custodian
+created: "2026-08-20"
+updated: "2026-08-20"
+depends_on: []
+tasks:
+  - id: T01
+    status: done
+    title: Establish whether kaizen-agentic packages already exist on forgejo
+  - id: T02
+    status: done
+    title: Publish current versions to the forgejo PyPI index
+  - id: T03
+    status: done
+    title: Repoint Makefile and all six docs in one change
+  - id: T04
+    status: done
+    title: Verify a clean install from forgejo on an uncached machine
+  - id: T05
+    status: done
+    title: Retire the gitea variables and close out
+state_hub_workstream_id: "ade14e03-98d8-5d0b-88d7-f7774114f050"
+---
+
+# KAIZEN-WP-0010 — Migrate package distribution to forgejo
+
+**Deadline: 2026-08-31.** Not a target — CoulombCore is being decommissioned by
+the operator on that date.
+
+## Why this exists
+
+`gitea.coulomb.social` runs on CoulombCore and serves two things: a container
+registry and a **PyPI package index** at `/api/packages/coulomb/pypi`. Both stop
+existing when the host does.
+
+kaizen-agentic's release workflow moved to Forgejo in early July, but the
+Makefile, consumer documentation, issue links, templates, and capability
+metadata did not move with it. This left a split-brain distribution story even
+though the destination already existed and was in use.
+
+### What breaks, and why it is worse than a broken link
+
+```
+Makefile:10   GITEA_PYPI_REPOSITORY_URL ?= https://gitea.coulomb.social/api/packages/$(GITEA_PACKAGE_OWNER)/pypi
+Makefile:11   GITEA_PYPI_SIMPLE_URL     ?= https://gitea.coulomb.social/api/packages/$(GITEA_PACKAGE_OWNER)/pypi/simple/
+```
+
+and the install instructions in **six** documents — `README.md`,
+`docs/GETTING_STARTED.md`, `docs/AGENT_DISTRIBUTION.md`,
+`docs/PACKAGE_RELEASE.md`, `docs/HELLO_WORLD_TUTORIAL.md`,
+`docs/CLI_CHEAT_SHEET.md` — all tell users to
+`pip install --extra-index-url …@gitea.coulomb.social/api/packages/coulomb/pypi/simple/`.
+
+These are the documented install instructions for the kaizen agent
+distribution. After 2026-08-31 every one fails, and it fails *looking like a
+broken package* rather than a retired host — so the person hitting it will debug
+the wrong thing.
+
+## The one rule for sequencing
+
+**Publish before you repoint.** A registry migration is not a find-and-replace.
+If the docs change first, they point at a 404 instead of a soon-to-be-404, which
+is strictly worse: today's instructions at least work. T01 and T02 come before
+T03, and T03 is a single change covering the Makefile and all six documents
+together — a half-migrated doc set is how the next repo gets missed.
+
+## Tasks
+
+```task
+id: KAIZEN-WP-0010-T01
+status: done
+priority: high
+state_hub_task_id: "63acba1a-f8e5-584d-9a85-b5e599e23681"
+```
+
+**Establish whether kaizen-agentic packages already exist on forgejo.** Check
+`forgejo.coulomb.social/api/packages/coulomb/pypi` for current package names and
+versions. This is a read; do not publish yet.
+
+Record what is there against what gitea holds. If forgejo already has current
+versions, T02 becomes a no-op and this finishes much faster than feared — worth
+five minutes before assuming a full republication.
+
+**Result (2026-08-20):** Forgejo anonymously serves the current `1.4.0` wheel
+and sdist. Gitea serves `1.1.0`, `1.2.0`, and `1.4.0`. The repository version
+and latest tag are both `1.4.0`.
+
+The simple package index is anonymously readable. If a write or authenticated
+API inventory is ever needed, route the Forgejo credential through `warden`
+and never paste a token into the Makefile or documentation.
+
+```task
+id: KAIZEN-WP-0010-T02
+status: done
+priority: high
+state_hub_task_id: "51ef8a2f-880e-5c93-ac88-c2468453f391"
+```
+
+**Publish current versions to the forgejo PyPI index.** Only the versions that
+matter — whatever the docs tell users to install, plus the current release.
+Historical versions are a judgement call: republish them only if something
+actually pins an old version.
+
+`issue-core/Makefile:250` is a working example of the forgejo `twine upload`
+target and is the shortest path to a correct invocation.
+
+**Result (2026-08-20):** No-op. The current `1.4.0` release was already on
+Forgejo, published by `.forgejo/workflows/publish-python-package.yml`; no
+credential request or duplicate upload was necessary.
+
+```task
+id: KAIZEN-WP-0010-T03
+status: done
+priority: high
+state_hub_task_id: "db50966e-1f3b-5fc0-ad8f-ea55f9b2f881"
+```
+
+**Repoint the Makefile and all six docs in one change.** Add
+`FORGEJO_PYPI_REPOSITORY_URL` / `FORGEJO_PYPI_SIMPLE_URL` and make them the
+default path, then update every install instruction listed above.
+
+Decide deliberately whether to keep the gitea variables temporarily for
+comparison or delete them now. `issue-core` kept both and now carries a legacy
+target that fails after 08-31 — a trap for whoever runs the wrong `make`. Given
+the deadline is nine days after this workplan is written, deleting outright is
+probably the better call here, but make it a decision rather than a default.
+
+Also update `GITEA_PACKAGE_USER` / `GITEA_PACKAGE_TOKEN` variable *names* if you
+keep the credential envelope — a variable called `GITEA_*` pointing at forgejo is
+the kind of thing that survives for years and confuses everyone who reads it.
+
+**Result (2026-08-20):** Removed the Gitea Make variables and target outright;
+`publish-forgejo` and `FORGEJO_PYPI_*` are the only release path. Consumer
+instructions now use the anonymously readable Forgejo index without embedding
+unnecessary credentials. Updated the six named documents plus operational
+references in contributing/scope/capability metadata, CLI feedback URLs, issue
+templates, project metadata, and packaged agent guidance.
+
+```task
+id: KAIZEN-WP-0010-T04
+status: done
+priority: high
+state_hub_task_id: "2db93b97-62c6-539b-b0a1-471dd0767014"
+```
+
+**Verify a clean install from forgejo on a machine with no cache.** A `pip
+install` that succeeds because the wheel is already in a local cache proves
+nothing. Use a fresh venv and `--no-cache-dir`, following the README's own
+instructions verbatim — if the documented command does not work, the docs are
+still wrong regardless of what the registry holds.
+
+This is the task that actually closes the risk. T01–T03 are preparation.
+
+**Result (2026-08-20):** A new temporary virtual environment installed
+`kaizen-agentic==1.4.0` with `--no-cache-dir` and the documented anonymous
+Forgejo extra index. Pip downloaded the wheel from Forgejo; both the CLI and
+Python package reported `1.4.0`.
+
+```task
+id: KAIZEN-WP-0010-T05
+status: done
+priority: medium
+state_hub_task_id: "36e9d767-c4f9-57f2-9be4-8e474d8aab11"
+```
+
+**Close out.** Remove any remaining gitea references from operational files
+(`Makefile`, docs, CI). Leave alone anything that merely *records* that gitea
+existed — history stays true after the host is switched off, and rewriting it to
+tidy a grep loses information.
+
+Tell `prj-state-hub-retirement` when T04 passes; this is tracked there as
+`SHR-WP-0002-T07` and is one of two items gating CoulombCore's retirement.
+
+**Result (2026-08-20):** No CoulombCore/Gitea host, package variable, publish
+target, workflow path, or issue-template path remains in operational files.
+Historical workplans and changelog entries were deliberately preserved.
+
+## Notes
+
+- Drafted by `prj-state-hub-retirement` on 2026-08-20 from the estate-wide sweep
+  that found this repo. The sequencing rule and the deadline are ours; **the
+  packaging decisions are yours** — nothing here has been applied to your files.
+- If any of this is wrong about how kaizen-agentic actually publishes, trust
+  your own knowledge and tell the project. The sweep read your Makefile and
+  docs; it did not run your release process.

workplans/KAIZEN-WP-0011-repository-health-normalization.md

@@ -0,0 +1,99 @@
+---
+id: KAIZEN-WP-0011
+type: workplan
+title: "Repository validation and metadata normalization"
+domain: agents
+repo: kaizen-agentic
+status: finished
+owner: codex
+topic_slug: custodian
+created: "2026-08-20"
+updated: "2026-08-20"
+state_hub_workstream_id: "ceae7cdc-2ed2-5276-a520-8f2a2d1fcc23"
+---
+
+# KAIZEN-WP-0011 — Repository validation and metadata normalization
+
+## Dependency validation
+
+```task
+id: KAIZEN-WP-0011-T01
+status: done
+priority: high
+state_hub_task_id: "673da081-e29e-5bff-ba53-cd588f9d9863"
+```
+
+
+Prevent empty dependency declarations such as `dependencies: []` from creating
+an empty-name dependency, and cover the behavior with a regression test.
+
+**Result:** dependency inputs are filtered before registration; the regression
+test passes and registry validation no longer reports an empty dependency.
+
+## Complete CI test coverage
+
+```task
+id: KAIZEN-WP-0011-T02
+status: done
+priority: high
+state_hub_task_id: "e02b5249-6f7c-5c22-b918-261e5a91031f"
+```
+
+
+Use the running interpreter for subprocess CLI tests and remove the Forgejo CI
+exclusion for the complete CLI error-handling test module.
+
+**Result:** the subprocess test uses `sys.executable`, the full module passes,
+and Forgejo CI now runs the complete test suite.
+
+## Documentation and capability metadata
+
+```task
+id: KAIZEN-WP-0011-T03
+status: done
+priority: medium
+state_hub_task_id: "0d31a1fa-7ac9-5476-a340-06761bd3f63a"
+```
+
+
+Align the documented agent count with the 20 packaged definitions and use
+`agents-sync-package` consistently for source/package parity guidance.
+
+**Result:** README, contributing guidance, capability source/index, and packaged
+agent guidance agree on 20 agents; parity guidance uses
+`make agents-sync-package`.
+
+## Workplan convention normalization
+
+```task
+id: KAIZEN-WP-0011-T04
+status: done
+priority: medium
+state_hub_task_id: "bfb22aee-f87a-5268-bd5c-cc8b43c99c4e"
+```
+
+
+Normalize completed workplan statuses to `finished`, rename workplan files to
+the canonical `KAIZEN-WP-NNNN-<slug>.md` convention, and update inbound links.
+
+**Result:** all eleven workplan filenames follow the canonical convention,
+completed top-level statuses use `finished`, and inbound documentation links
+were updated. Stable workplan and task IDs were not changed.
+
+## Verification and closeout
+
+```task
+id: KAIZEN-WP-0011-T05
+status: done
+priority: high
+state_hub_task_id: "da4970c6-7da5-5a25-b70a-f12abfd97307"
+```
+
+
+Run the full test, release, agent-validation, and State Hub consistency checks;
+record the outcome and close the workplan.
+
+**Result:** full pytest, `make release-check`, `make agents-validate`, and
+`git diff --check` pass. `statehub fix-consistency` passes; all prefix and
+status warnings are eliminated. UUID registration is deferred to the production
+registrar, requested through State Hub message `d0d38ee7`.

workplans/KAIZEN-WP-0012-scope-intent-role-automation-assessment.md

@@ -0,0 +1,86 @@
+---
+id: KAIZEN-WP-0012
+type: workplan
+title: "Scope, intent, and role automation readiness assessment"
+domain: agents
+repo: kaizen-agentic
+status: finished
+owner: codex
+topic_slug: custodian
+created: "2026-08-20"
+updated: "2026-08-20"
+state_hub_workstream_id: "4429682b-2385-5323-a996-fcce83ff41c8"
+---
+
+# KAIZEN-WP-0012 — Scope, intent, and role automation readiness assessment
+
+## Reconcile SCOPE with implemented capabilities
+
+```task
+id: KAIZEN-WP-0012-T01
+status: done
+priority: high
+state_hub_task_id: "9536da60-6336-5f95-b598-002406cc12f2"
+```
+
+
+Refresh `SCOPE.md` from the current repository state, including metrics,
+engagement, Role package, scheduling-contract, and ecosystem boundaries.
+
+**Result:** `SCOPE.md` now describes the implemented blueprint, measurement,
+schedule, engagement, and integration surfaces and assigns runtime, schedule,
+role-catalog, assignment, credential, and policy ownership explicitly.
+
+## Assess repository against INTENT
+
+```task
+id: KAIZEN-WP-0012-T02
+status: done
+priority: high
+state_hub_task_id: "5f065e75-7217-5bcc-bdcd-ffa43751d1d2"
+```
+
+
+Map the implemented system and known gaps to the stable purpose, ownership
+boundaries, design principles, and maturity target in `INTENT.md`.
+
+**Result:** the dated assessment records strong intent alignment, incomplete
+template/idempotency/refinement maturity, and the remaining path to the full
+define/deploy/measure/refine/commercialize target. Stray trailing draft text was
+removed from `INTENT.md` without changing its strategy.
+
+## Define automated role-agent readiness path
+
+```task
+id: KAIZEN-WP-0012-T03
+status: done
+priority: high
+state_hub_task_id: "196f7a71-2edc-5ddc-b659-18ab116227dd"
+```
+
+
+Document the existing activity-core → rein-aharness execution path and the
+remaining contracts, ownership decisions, controls, and pilot work needed to
+schedule agents that perform role-engine-defined roles.
+
+**Result:** the readiness document traces the existing live scheduling/runtime
+backbone, identifies the absent assignment owner and structured run fields,
+assigns changes by repository, and proposes a read-only Community Manager pilot.
+
+## Validate and close out
+
+```task
+id: KAIZEN-WP-0012-T04
+status: done
+priority: medium
+state_hub_task_id: "00bb2f93-7ee7-5b57-b53d-d19e3a395047"
+```
+
+
+Run documentation, repository, test, and State Hub consistency checks; record
+the evidence and leave workplan status synchronized with the result.
+
+**Result:** full pytest, `make release-check`, `make agents-validate`, and
+`git diff --check` pass. `statehub fix-consistency` passes with the existing
+capability-tag advisory and production-registrar deferral for workplan UUIDs;
+the generated work-record index includes KAIZEN-WP-0012.

workplans/KAIZEN-WP-0013-agent-workforce-goal-budget-governance.md

@@ -0,0 +1,90 @@
+---
+id: KAIZEN-WP-0013
+type: workplan
+title: "Agent workforce, goal, leadership, and budget governance"
+domain: agents
+repo: kaizen-agentic
+status: finished
+owner: codex
+topic_slug: custodian
+created: "2026-08-20"
+updated: "2026-08-20"
+state_hub_workstream_id: "ff7a3f4b-e116-5040-828f-19940e164bb5"
+---
+
+# KAIZEN-WP-0013 — Agent workforce, goal, leadership, and budget governance
+
+## Assess sibling resource-management repositories
+
+```task
+id: KAIZEN-WP-0013-T01
+status: done
+priority: high
+state_hub_task_id: "0bb596c2-f793-5f95-a9b9-8c711161ea16"
+```
+
+
+Review agentic-resources and human-resources intent, scope, workplans, and
+implementation evidence, plus authoritative budget and resource-control
+boundaries.
+
+**Result:** agentic-resources is not intent-only: it implements a tested
+multi-agent session capture, pattern curation/distribution, measurement, and
+retrospective loop. Its root SCOPE is stale and it does not yet implement agent
+assignments, goal allocation, or portfolio budgets. Human-resources remains a
+planning/workflow-registry scaffold. Fin-hub owns budgets and viability signals;
+resource-control owns technical resource and cost evidence.
+
+## Define goals, leadership, and constrained allocation model
+
+```task
+id: KAIZEN-WP-0013-T02
+status: done
+priority: high
+state_hub_task_id: "baa78e9b-570b-565e-b1b2-e96eb270a140"
+```
+
+
+Extend the role-agent readiness architecture with explicit organizational
+goals, leadership/accountability, agent-workforce allocation, and layered
+financial, resource, token, time, and attention constraints.
+
+**Result:** the assessment now defines a leadership-to-workforce control spine,
+StrategicGoal, LeadershipMandate, ResourceEnvelope, RoleAssignment, and
+AgentInstance separation, layered constraint authority/enforcement, and a
+goal/budget-correlated pilot path.
+
+## Reconcile KaizenAgentic ecosystem scope
+
+```task
+id: KAIZEN-WP-0013-T03
+status: done
+priority: medium
+state_hub_task_id: "951aff7d-ac14-5c98-9a16-5362b4e66a48"
+```
+
+
+Update SCOPE ownership mappings so agentic-resources, human-resources, fin-hub,
+resource-control, and organization-specific leadership sources are represented
+without moving their responsibilities into kaizen-agentic.
+
+**Result:** SCOPE now maps organization leadership, role-engine,
+agentic-resources, human-resources, fin-hub, resource-control, activity-core,
+and rein-aharness to distinct ownership concerns.
+
+## Validate and close out
+
+```task
+id: KAIZEN-WP-0013-T04
+status: done
+priority: medium
+state_hub_task_id: "d1bf7400-def9-5ad5-adc8-30a728e463fd"
+```
+
+
+Run repository checks, synchronize generated work records and State Hub, record
+the findings, and close the workplan.
+
+**Result:** full pytest, `make release-check`, `make agents-validate`, and
+`git diff --check` pass. State Hub consistency and production UUID registration
+are handled through the normal closeout path.

workplans/KAIZEN-WP-0014-repository-consolidation.md

@@ -0,0 +1,103 @@
+---
+id: KAIZEN-WP-0014
+type: workplan
+title: "Repository documentation, execution, and custody consolidation"
+domain: agents
+repo: kaizen-agentic
+status: finished
+owner: codex
+topic_slug: repository-consolidation
+created: "2026-08-20"
+updated: "2026-08-20"
+state_hub_workstream_id: "5f6aba9a-0b6d-5887-9876-6b56715d116a"
+---
+
+# Repository documentation, execution, and custody consolidation
+
+Bring the public repository description, capability registration, automated execution
+documentation, and remaining pilot evidence custody into agreement with the implemented
+Kaizen Agentic architecture.
+
+## Register and baseline the workplan
+
+```task
+id: KAIZEN-WP-0014-T01
+status: done
+priority: high
+state_hub_task_id: "66009a75-07a9-5a2e-bff3-7c341e88f036"
+```
+
+
+Register this file-first workplan through State Hub consistency tooling and capture the
+current repository baseline before making changes.
+
+## Refresh repository-facing documentation
+
+```task
+id: KAIZEN-WP-0014-T02
+status: done
+priority: high
+state_hub_task_id: "172f5af3-18c7-56ad-b873-7a6d990fd4b7"
+```
+
+
+Update the README and related repository-facing descriptions to reflect the current
+release, packaged agents, CLI surfaces, governance model, and integration boundaries.
+
+## Refresh capability registration metadata
+
+```task
+id: KAIZEN-WP-0014-T03
+status: done
+priority: high
+state_hub_task_id: "1a6b5aac-8661-5698-a9ac-a456aaf76aa4"
+```
+
+
+Align the capability record and capability index with the agents domain and the current
+memory, metrics, scheduling, role, engagement, and downstream-consumer surfaces.
+Normalize the repo classification to canonical capability-family tags.
+
+## Document the current scheduled-execution contract
+
+```task
+id: KAIZEN-WP-0014-T04
+status: done
+priority: high
+state_hub_task_id: "5916585a-b9e9-5f66-8c37-4969dff639c9"
+```
+
+
+Update the activity-core integration material to describe the durable `ops_run`,
+versioned Glas profile, and selected-rein execution path while retaining manual
+execution as a supported fallback.
+
+## Resolve pilot-vault custody
+
+```task
+id: KAIZEN-WP-0014-T05
+status: done
+priority: high
+state_hub_task_id: "d5342ff3-4bf9-5f8b-b2d8-2f3cefbd95f5"
+```
+
+
+Assess the Railiance pilot evidence, define its present classification and owner, select
+the appropriate client-side custody target, and establish a safe handoff contract. Do not
+move or delete client material until the receiving repository accepts custody.
+
+## Validate and close out
+
+```task
+id: KAIZEN-WP-0014-T06
+status: done
+priority: high
+state_hub_task_id: "23a06a0c-1e16-59b8-9f6f-10e4100bbf53"
+```
+
+
+Run repository validation, synchronize file state into State Hub, record progress, and
+publish the completed work.
+
+Validation completed with repository standards, lint, and the full test suite:
+152 passed and 2 existing optional-integration skips.