# 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 2–3 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." ```