generated from coulomb/repo-seed
Bootstrap coulomb-loop engagement: governance, loops, and activity definitions.
Register with state-hub, accept DEC-001–004 and ADR-004 rotation policy, scaffold pilot roster, hourly ActivityDefinition copies, and bootstrap log after schedule init on three custodian pilot repos.
This commit is contained in:
72
docs/decisions/DEC-001-pilot-roster-scope.md
Normal file
72
docs/decisions/DEC-001-pilot-roster-scope.md
Normal file
@@ -0,0 +1,72 @@
|
||||
# DEC-001 — Pilot Roster Scope
|
||||
|
||||
**Status:** accepted
|
||||
**Date:** 2026-06-18
|
||||
**Owner:** Bernd (Coulomb operator)
|
||||
**Blocks:** LOOP-WP-0001 T02, LOOP-WP-0003 T05
|
||||
|
||||
---
|
||||
|
||||
## Question
|
||||
|
||||
Which repositories should participate in the **bootstrap-phase** self-improvement
|
||||
loops before fleet expansion?
|
||||
|
||||
## Context
|
||||
|
||||
LOOP-WP-0001 proposes three custodian-domain pilots:
|
||||
|
||||
- `kaizen-agentic` — supplier dogfood
|
||||
- `the-custodian` — state-hub / coordination operator
|
||||
- `activity-core` — scheduler owner
|
||||
|
||||
The full Coulomb fleet has **57 state-hub repos** across 12 domains. Hourly
|
||||
bootstrap on all repos would create unsustainable task volume.
|
||||
|
||||
## Options
|
||||
|
||||
### A — Custodian pilot only (recommended default)
|
||||
|
||||
**3 repos:** `kaizen-agentic`, `the-custodian`, `activity-core`
|
||||
|
||||
| Pros | Cons |
|
||||
|------|------|
|
||||
| All loop infrastructure owners in one batch | Does not exercise coulomb_social domain repos |
|
||||
| Minimal noise; fast E2E proof | Fleet improvement delayed |
|
||||
| Aligns with supplier WP-0006 pilot design | |
|
||||
|
||||
### B — Custodian pilot + one coulomb_social repo
|
||||
|
||||
**4 repos:** option A + `vergabe-teilnahme`
|
||||
|
||||
| Pros | Cons |
|
||||
|------|------|
|
||||
| Validates engagement under customer domain | Mixed stack (Django app vs infra repos) |
|
||||
| Product-facing dogfood | Extra setup for app-specific agents |
|
||||
|
||||
### C — Domain-stratified mini-pilot (5 repos)
|
||||
|
||||
**5 repos:** option A + `reuse-surface` + `vergabe-teilnahme`
|
||||
|
||||
| Pros | Cons |
|
||||
|------|------|
|
||||
| Covers helix_forge registry + coulomb_social product | More hourly tasks; slower bootstrap exit |
|
||||
| Exercises LOOP-WP-0003 registry hygiene early | |
|
||||
|
||||
## Recommendation
|
||||
|
||||
**Option A** for bootstrap; expand via LOOP-WP-0003 domain rollout after
|
||||
LOOP-WP-0004 approves first promotion to daily.
|
||||
|
||||
## Decision record
|
||||
|
||||
| Field | Value |
|
||||
|-------|-------|
|
||||
| Chosen option | **A** — custodian pilot only (3 repos) |
|
||||
| Decided by | Bernd Worsch |
|
||||
| Decided at | 2026-06-18 |
|
||||
| Notes | Fleet expansion via expansion_queue; rotation per ADR-004 when diminishing returns detected |
|
||||
|
||||
## On approval
|
||||
|
||||
Update `loops/kaizen-stack/roster.yaml` and close LOOP-WP-0001 T02.
|
||||
67
docs/decisions/DEC-002-event-vs-sweep-quality.md
Normal file
67
docs/decisions/DEC-002-event-vs-sweep-quality.md
Normal file
@@ -0,0 +1,67 @@
|
||||
# DEC-002 — Quality Escalation Trigger Strategy
|
||||
|
||||
**Status:** accepted
|
||||
**Date:** 2026-06-18
|
||||
**Owner:** Bernd
|
||||
**Blocks:** LOOP-WP-0002 T03, T05, T07
|
||||
|
||||
---
|
||||
|
||||
## Question
|
||||
|
||||
Should reactive quality escalation (LOOP-WP-0002) use **event-driven** triggers,
|
||||
**hourly sweep** polling, or **both**?
|
||||
|
||||
## Context
|
||||
|
||||
Supplier draft `low-success-rate-review` expects NATS event `kaizen.metrics.recorded`.
|
||||
That emitter does not exist in `kaizen-agentic metrics record` today (KAIZEN-WP-0008 T03).
|
||||
|
||||
LOOP-WP-0002 proposes hourly sweep as bootstrap scaffolding until events ship.
|
||||
|
||||
## Options
|
||||
|
||||
### A — Sweep first, events later (recommended)
|
||||
|
||||
1. Bootstrap: hourly `discover_kaizen_projects` sweep only
|
||||
2. After KAIZEN-WP-0008 ships emitter: enable event definition; demote sweep to daily backup
|
||||
|
||||
| Pros | Cons |
|
||||
|------|------|
|
||||
| Unblocks LOOP-WP-0002 without supplier code | Higher hub load during bootstrap |
|
||||
| Proven pattern (activity-core shell resolvers) | Latency up to 1 hour |
|
||||
|
||||
### B — Block until event emitter ships
|
||||
|
||||
Wait for `metrics record --emit-event` before any LOOP-WP-0002 automation.
|
||||
|
||||
| Pros | Cons |
|
||||
|------|------|
|
||||
| Clean architecture | Delays reactive loop entirely |
|
||||
| No duplicate triggers | LOOP-WP-0004 lacks quality signal data |
|
||||
|
||||
### C — Dual from day one
|
||||
|
||||
Run hourly sweep **and** events when available; dedupe by `(repo, agent, hour)`.
|
||||
|
||||
| Pros | Cons |
|
||||
|------|------|
|
||||
| Fastest signal once events land | Duplicate task risk; complex dedupe |
|
||||
| | Harder to tune false-positive rate |
|
||||
|
||||
## Recommendation
|
||||
|
||||
**Option A.** Document emitter contract now (LOOP-WP-0002 T03); implement in
|
||||
KAIZEN-WP-0008; keep sweep as documented backup per ADR-003 stabilize phase.
|
||||
|
||||
## Decision record
|
||||
|
||||
| Field | Value |
|
||||
|-------|-------|
|
||||
| Chosen option | **A** — sweep first, events later |
|
||||
| Decided by | Bernd Worsch |
|
||||
| Decided at | 2026-06-18 |
|
||||
|
||||
## On approval
|
||||
|
||||
Update `loops/quality-escalation/thresholds.yml` trigger section.
|
||||
66
docs/decisions/DEC-003-activity-definition-ownership.md
Normal file
66
docs/decisions/DEC-003-activity-definition-ownership.md
Normal file
@@ -0,0 +1,66 @@
|
||||
# DEC-003 — ActivityDefinition Copy vs Reference
|
||||
|
||||
**Status:** accepted
|
||||
**Date:** 2026-06-18
|
||||
**Owner:** Bernd
|
||||
**Blocks:** LOOP-WP-0001 T04, activity-core sync workflow
|
||||
|
||||
---
|
||||
|
||||
## Question
|
||||
|
||||
How should coulomb-loop ActivityDefinitions relate to kaizen-agentic supplier templates?
|
||||
|
||||
## Context
|
||||
|
||||
ADR-002 assigns ActivityDefinition **copies** to the customer repo. activity-core
|
||||
syncs from its own catalog path (ACT-ADR-002). Two sync models are possible.
|
||||
|
||||
## Options
|
||||
|
||||
### A — Customer-owned copies (recommended)
|
||||
|
||||
Copy supplier templates into `coulomb-loop/activity-definitions/`. activity-core
|
||||
syncs from coulomb-loop path (or vendored subtree). Customer edits cron, labels,
|
||||
roster params without supplier release.
|
||||
|
||||
| Pros | Cons |
|
||||
|------|------|
|
||||
| Coulomb controls cadence ramp (hourly bootstrap) | Drift from supplier templates |
|
||||
| Matches ADR-002 | Manual merge when supplier updates templates |
|
||||
|
||||
### B — Supplier catalog only
|
||||
|
||||
Reference supplier repo path; activity-core syncs `kaizen-agentic/docs/integrations/activity-definitions/`.
|
||||
|
||||
| Pros | Cons |
|
||||
|------|------|
|
||||
| Single source of truth | Hourly bootstrap crons don't match supplier weekly defaults |
|
||||
| Less copy maintenance | Customer cannot tune without supplier PR |
|
||||
|
||||
### C — Hybrid manifest
|
||||
|
||||
`coulomb-loop/activity-definitions/manifest.yaml` lists supplier source + local overrides (cron, enabled, labels). activity-core merge tool applies patches.
|
||||
|
||||
| Pros | Cons |
|
||||
|------|------|
|
||||
| Drift-aware automation | Requires new activity-core or coulomb-loop tooling |
|
||||
| Best long-term for multiple customers | Not available today |
|
||||
|
||||
## Recommendation
|
||||
|
||||
**Option A** for bootstrap (minimal tooling). Track **Option C** in KAIZEN-WP-0008
|
||||
as supplier playbook enhancement for second customer.
|
||||
|
||||
## Decision record
|
||||
|
||||
| Field | Value |
|
||||
|-------|-------|
|
||||
| Chosen option | **A** — customer-owned copies |
|
||||
| Decided by | Bernd Worsch |
|
||||
| Decided at | 2026-06-18 |
|
||||
| Notes | Option C hybrid manifest tracked in KAIZEN-WP-0008 T08 |
|
||||
|
||||
## On approval
|
||||
|
||||
Proceed with LOOP-WP-0001 T04 copy step; document merge procedure in `loops/kaizen-stack/supplier-notes.md`.
|
||||
70
docs/decisions/DEC-004-supplier-playbook-priority.md
Normal file
70
docs/decisions/DEC-004-supplier-playbook-priority.md
Normal file
@@ -0,0 +1,70 @@
|
||||
# DEC-004 — Supplier Playbook Delivery Priority
|
||||
|
||||
**Status:** accepted
|
||||
**Date:** 2026-06-18
|
||||
**Owner:** Bernd
|
||||
**Blocks:** KAIZEN-WP-0008 sequencing
|
||||
|
||||
---
|
||||
|
||||
## Question
|
||||
|
||||
What should kaizen-agentic (supplier) prioritize **before** vs **after** first
|
||||
hourly loop smoke test?
|
||||
|
||||
## Context
|
||||
|
||||
KAIZEN-WP-0008 bundles supplier obligations: customer-repo template, event emitter,
|
||||
engagement CLI, playbook. Full delivery before smoke test delays customer value;
|
||||
minimal delivery risks rework.
|
||||
|
||||
## Options
|
||||
|
||||
### A — Smoke-first, playbook parallel (recommended)
|
||||
|
||||
**Before smoke test (KAIZEN-WP-0008 Part 1):**
|
||||
|
||||
- Document customer-repo layout (reference: coulomb-loop)
|
||||
- Support pilot `schedule init` on target repos (docs only; CLI exists)
|
||||
|
||||
**After smoke test (KAIZEN-WP-0008 Part 2):**
|
||||
|
||||
- `metrics record --emit-event`
|
||||
- `schedule init --engagement` scaffold
|
||||
- Playbook v1 in supplier repo
|
||||
|
||||
| Pros | Cons |
|
||||
|------|------|
|
||||
| Fastest proof of LOOP-WP-0001 | Playbook incomplete until smoke passes |
|
||||
| Playbook informed by real friction | |
|
||||
|
||||
### B — Playbook-first
|
||||
|
||||
Complete customer-repo template and engagement CLI before any activity-core enable.
|
||||
|
||||
| Pros | Cons |
|
||||
|------|------|
|
||||
| Second customer ready sooner | Delays all loop automation |
|
||||
| | Speculative without smoke data |
|
||||
|
||||
### C — Automation-first
|
||||
|
||||
Prioritize activity-core resolver + event emitter; defer playbook to LOOP-WP-0004 T07.
|
||||
|
||||
| Pros | Cons |
|
||||
|------|------|
|
||||
| Unblocks LOOP-WP-0002 events | Customer repo conventions undocumented |
|
||||
| Cross-repo focus | Harder for humans to operate engagement |
|
||||
|
||||
## Recommendation
|
||||
|
||||
**Option A.** Record friction in `loops/*/supplier-notes.md` during smoke test;
|
||||
feed into playbook draft at LOOP-WP-0004 T07 / KAIZEN-WP-0008 Part 2.
|
||||
|
||||
## Decision record
|
||||
|
||||
| Field | Value |
|
||||
|-------|-------|
|
||||
| Chosen option | **A** — smoke-first, playbook parallel |
|
||||
| Decided by | Bernd Worsch |
|
||||
| Decided at | 2026-06-18 |
|
||||
Reference in New Issue
Block a user