Development plan proposal

.github/workflows/publish-tasks.yml

@@ -0,0 +1,23 @@
+name: Publish tasks as issues
+
+on:
+  push:
+    branches: [main]
+    paths:
+      - planning/plan.yaml
+      - planning/tasks/**
+      - scripts/publish-tasks.py
+  workflow_dispatch:
+
+permissions:
+  contents: read
+  issues: write
+
+jobs:
+  publish:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - run: python3 scripts/publish-tasks.py
+        env:
+          GH_TOKEN: ${{ github.token }}

docs/adr/20260824-one-bco-campaign-executor-in-the-mvp.md

@@ -0,0 +1,40 @@
+# ADR-20260824: One BCO campaign executor in the MVP
+
+## Status
+
+Proposed — 2026-08-24
+
+## Context
+
+The component design used campaign leases to let multiple BCO campaign executors share work safely.
+The MVP does not need horizontal executor scaling, automatic executor failover, or overlapping
+executor rollouts. Implementing leases and safe lease handoff would add work before those deployment
+modes provide user value.
+
+## Decision
+
+The whole MVP deployment runs exactly one BCO campaign executor. Campaign leases are not part of the
+MVP. Deployment updates stop the current executor before starting its replacement, and deployment
+configuration must not allow more than one campaign executor.
+
+This restriction applies to the stateful campaign executor. It does not decide how other stateless
+services may be deployed.
+
+## Consequences
+
+- The MVP avoids lease storage, renewal, expiry, fencing, and handoff behavior.
+- The executor still saves the next intended action and completed downstream results so a later
+  process can resume after the previous process has stopped.
+- The MVP has no automatic campaign-executor failover and no overlapping executor rollout.
+- A deployment must stop the old executor before starting a replacement. Recovery begins only after
+  the previous executor has exited.
+- Stable action keys and downstream idempotency are still needed for a crash after a downstream call
+  succeeds but before BCO saves its reply. A single executor does not remove that crash window.
+
+## Required design updates
+
+Update `docs/architecture.md`, `docs/bisection-data-model.md`, `docs/components.md`,
+`docs/components/bco.md`, and `docs/components/state-store.md`. Remove lease behavior from
+`docs/diagrams/ownership-boundary.mmd`, `docs/diagrams/recovery.mmd`, and
+`docs/diagrams/single-candidate-step.mmd`. The updated documents must describe one campaign executor
+and persisted next action without campaign leases.

planning/README.md

@@ -0,0 +1,66 @@
+# Implementation plan
+
+[`plan.yaml`](plan.yaml) defines execution order and dependencies. Each file under [`tasks/`](tasks/)
+defines one proposed GitHub issue.
+
+## Plan anatomy
+
+```yaml
+version: PLAN-VERSION-NUMBER
+phases:
+  - phase: PHASE-NUMBER, recommended execution order
+    goal: "OUTCOME DESCRIPTION"
+    tasks:
+      group-name/task-name.md:
+        stream: "STREAM-NAME, i.e working group or component"
+        title: "TASK TITLE"
+        priority: TASK-PRIORITY, high|medium|low
+        delivers: "concrete value produced by the task"
+        depends_on:
+          - group-name/some-other-task.md
+```
+
+A phase groups the tasks that deliver one milestone. A task may start when every `depends_on` task
+is complete.
+
+## Task anatomy
+
+```markdown
+---
+stream: "BCO"
+topic: "Short classification"
+priority: high
+publish: false
+---
+
+# Task title
+
+## Description
+
+What must change and why.
+
+## Contribution
+
+- Delivers: Concrete capability or assurance.
+
+## Acceptance criteria
+
+- [ ] Short, verifiable result.
+
+## Sources
+
+- [Owning design or contract](../../../docs/example.md)
+```
+
+Keep acceptance criteria short and testable. Use `Sources` for the documents that define the required
+behavior.
+
+## Publishing tasks to GitHub
+
+- `publish: false`: the task is a draft. A GitHub publishing action must skip it. Its path may change.
+- `publish: true`: the task is approved. A GitHub publishing action may create or update its issue.
+- After an issue is created, keep the task path unchanged so the action can match the file to that issue.
+- The task title and body may still change after publication.
+
+This branch does not contain the GitHub publishing action. Changing the flag alone does not create or update
+an issue.