binky-control/DecisionQueue.md
tegwick 5f5f74c017
All checks were successful
Work Records / validate (push) Successful in 22s
CUST-WP-0061-T05: retarget queue closures to WORK-RECORDS.md (generated)
Convention change, not new code: closing an item now means setting its
terminal status (status: closed/resolved/done + outcome where
applicable) directly on the item's own yaml block in place, instead of
deleting it and hand-writing a bullet in a separate "Completed"/
"Resolved decisions" log. WORK-RECORDS.md (CUST-WP-0061-T04, generated
by fix-consistency's C-33) already lists every closed/resolved/done
record with status/lane/source -- that supersedes the hand-maintained
logs as the going-forward view.

- AutopilotWorkQueue.md: closing note added; "## Completed" relabeled
  "(historical -- pre-canon, 2026-07-21)", frozen as-is, nothing
  migrated or deleted
- DecisionQueue.md: closing note added -- its "## Resolved decisions"
  entries were already structured as in-place yaml blocks with
  status: resolved (ahead of AWQ's convention already), so this only
  clarifies the log is superseded going forward, no structural change
- OfficeHourQueue.md: closing note added -- items already live under
  "## Queued items" with status: queued|prepared|done in place, no
  separate log ever existed here
- OperatingRhythm.md: queue-hygiene checklist updated to describe
  in-place status transitions instead of "moved to the log"; added
  item 5 noting WORK-RECORDS.md needs no hand-maintenance

Re-ran fix-consistency: WORK-RECORDS.md content unchanged (correctly
idempotent -- these were prose-only edits, no yaml block content
changed).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-21 01:54:40 +02:00

116 lines
4.4 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Decision Queue
> Status: live document — decisions awaiting the founder, as prepared
> approval packages (`AutonomyPolicy.md`). Agents append; Bernd resolves.
>
> **Resolving a decision (CUST-WP-0061-T05, 2026-07-21):** set
> `status: resolved` (plus `outcome`, `resolved_at`, `resolved_by`) directly
> on the item's own yaml block in place — don't move it to a separate log.
> `WORK-RECORDS.md` (generated by `statehub fix-consistency`) is the
> always-current view of every decision including resolved ones; that
> replaces the "## Resolved decisions" log below as the going-forward
> record. Existing log entries are historical (pre-canon) and stay as
> prose.
## Item template
```yaml
id: DEC-2026-NNN
title: ""
lane: yellow | orange | red
status: prepared | resolved | deferred
created_at: ""
needed_by: ""
attention_cost: ""
agent_recommendation: ""
evidence: []
options: [approve, reject, revise, defer]
fallback_if_no_response: ""
```
## Open decisions
### DEC-2026-003 — Go for executor cutover (retire the cron bridge)
```yaml
id: DEC-2026-003
title: "Execute BINKY-WP-0004-T06: enable harness-scheduled Binky definitions, retire workstation cron bridge"
lane: yellow
status: prepared
state_hub_decision_id: "d47d288f-a76f-4e2f-b039-330028824397"
created_at: "2026-07-18"
needed_by: "soft — each day of delay keeps the workstation cron dependency alive"
attention_cost: "~5 min: skim runbook gates, say go/no-go"
agent_recommendation: "approve — all three gates cleared as of 2026-07-18
(DEC-2026-002 resolved; Red-lane Lanes 23 provisioned; harness live on
Railiance with tenant #1 onboarded and three definition proof runs)"
evidence:
- integrations/executor-cutover-runbook.md
- integrations/harness-tenant-onboarding.md
options: [approve, reject, revise, defer]
fallback_if_no_response: "cron bridge keeps running; no degradation, but
workstation-independence milestone stalls"
```
## Resolved decisions
### DEC-2026-004 — Qonto MCP: create API key, provision OpenBao lane (read-only use)
```yaml
id: DEC-2026-004
title: "Provision Qonto API credentials for the self-hosted Qonto MCP server (read-only harness lane)"
lane: red
status: resolved
outcome: approved
resolved_at: "2026-07-19"
resolved_by: Bernd
state_hub_decision_id: "a2a9de69-5bc1-434a-9a61-508ff3c12edf"
consequence: "Founder executes the Red-lane provisioning at the next office
hour, bundled with OH-2026-003's Qonto dashboard review: API key under
/settings/integrations + bao kv put tenants/binky/qonto/api (procedure in
integrations/qonto-mcp.md), plus plan tier/fee note for CostRunRate row 4.
Design as approved: self-hosted qonto/qonto-mcp-server, read-only via
harness tool allow-list, payments founder-only forever. BINKY-WP-0005-T05
(first read-only pull) unblocks after provision."
evidence:
- integrations/qonto-mcp.md
- workplans/BINKY-WP-0005-qonto-mcp-integration.md
```
### DEC-2026-002 — Agent harness: one shared runtime repo
```yaml
id: DEC-2026-002
title: "Executor worker ownership: new thin repo vs. inside activity-core"
lane: yellow
status: resolved
outcome: "approved, rescoped: single shared `agent-harness` repo for ALL projects"
resolved_at: "2026-07-17"
resolved_by: Bernd
state_hub_decision_id: "63620255-59d0-4109-bdee-4d0644c450e5"
consequence: "Three-layer model: blueprints in kaizen-agentic; instances as
declarative manifests + .kaizen state in consuming repos (no code, no
credentials, named tool profiles, pinned harness major); agent-harness is
the single credential holder / policy enforcer, deployed once on Railiance,
multi-tenant — binky-control is tenant #1. executor-worker prototype
adopted as the harness seed. Recorded as agent-harness ADR-001 +
docs/architecture.md; foundation work in HARNESS-WP-0001."
```
### DEC-2026-001 — Ratify company canon v0
```yaml
id: DEC-2026-001
title: "Ratify company canon v0 (INTENT, AutonomyPolicy, and companion docs)"
lane: red
status: resolved
state_hub_decision_id: "14383059-7698-4566-a664-858e3d49ee8d"
outcome: approved with edits
resolved_at: "2026-07-16"
resolved_by: Bernd
edits: "Railiance role refined to reliable deployment & operations (code → SaaS ecosystems and products); Operational Knowledge added as fourth ecosystem pillar (value from experience). Edits propagated to EcosystemMap.md and DogfoodPolicy.md."
evidence:
- INTENT.md (v1.0)
- AutonomyPolicy.md
consequence: "Canon v1.0 in force; AutonomyPolicy lanes active; Green/Blue work may proceed unattended."
```