settled-reach/decisions/questions-process.md

Open Questions — Process

How the team works: workflow mechanics, cadence, ceremony, release rhythm.

---

Q-096: Replace sprint workflow with kanban + milestones

• Status: Resolved — see D-221
• Date raised: 2026-04-20
• Last updated: 2026-05-01 (expanded from "should we?" to concrete proposal with test plan)
• Raised by: Jeroen
• Assigned to: Jeroen (final call)

---

Problem Statement

Sprints were introduced when the workflow was framed as Scrum-adjacent. Across 38 sprints, the failure modes have sharpened beyond the original "ceremony overhead" concern into structural problems with how agents interpret sprint-shaped work.

Original concerns (Sprint 36):

Mechanism	Compensates for	Applies here?
Time-box (1-2 weeks)	Humans need deadline pressure to scope	No — Claude scopes on demand
Retro	Team learning ritual, morale	No — adjustments land as rule/memory edits immediately
Burndown / velocity	Estimation & planning for multi-person roadmaps	No — solo dev, no external stakeholders
Demoable increments	External stakeholder cadence	No external stakeholders
Sprint-kickoff ceremony	Re-energize after context loss	Context loss is per-session, not per-sprint
Version bump at sprint close	Predictable shippable cadence	v0.1.{sprint_number} doesn't reflect feature progress

New failure modes observed (Sprint 37-38):

1. Ticket-as-contract. Agents execute the letter of the ticket instead of reading the code and doing what's actually right. If the ticket says "implement X using approach Y," the agent implements Y even when the codebase clearly suggests Z. The ticket becomes a shield against thinking.

2. Artificial delay. Work that's ready gets parked because it's "next sprint." Work that's blocked gets thrashed because it's "this sprint." The sprint boundary creates urgency and delay simultaneously.

3. Role theater. Agents treat team-scope restrictions (server team can't touch client files) as hard boundaries when the fix is a one-liner. This models a human org chart, not the reality of one person and a context window.

4. Order rigidity. Agents unwilling to reorder work when dependencies shift, because the briefing prescribed a sequence. Sprint briefings go stale instantly (Sprint 38 server briefing was missing 26 tickets within a day of creation).

5. Locking on bad design. Agents commit to approaches described in tickets even when implementation reveals the design was wrong. The ticket's authority overrides what the code is telling them.

6. Self-review collapse. Coding agents write code, create the PR, review their own PR, approve it, and push — all in one convergent context. The adversarial review pipeline collapses because the reviewer has all the author's context and biases. PR comments aren't posted, review gates are skipped, the entire point of separate reviewer personalities is defeated. Requires constant human intervention to enforce.

Compounding factors (May 2026):

• Claude Code team-mode harness partially broken (v2.1.123: custom agent types missing SendMessage, shutdown doesn't work, TeamDelete doesn't kill panes). Workaround exists but fragile.
• Opus 4.7 prompt quality ("floatiness") makes the problem worse — agents are already less precise, and rigid ticket framing doesn't compensate, it amplifies.

---

Proposal: Kanban + Milestones + Adversarial Personalities

What stays:

Element	Why it stays
Cascade phases	Macro direction — what to build in what order
Agent personalities + briefings	Adversarial diversity — the real purpose is breaking convergence patterns by seeding different thinking via personality prompts. Not role-play, divergence engines.
D-records	Decisions are decisions regardless of process
Tickets	Track what needs doing — but descriptive, not prescriptive
Workshops	The format where adversarial diversity pays off. Unchanged.
Rules/memory	Live institutional knowledge, immediate course correction

What changes:

Old	New
Sprint numbers, sprint boundaries	Milestones tied to concrete deliverables (cascade phase, feature gate)
Sprint briefings (pre-baked, go stale)	Session startup: ticket list --status in_progress + blocked-by graph
Team branches (sprint-N/server)	Topic branches per logical chunk, any agent can touch any file
File-scope restrictions per agent	Removed — personalities guide perspective, not file access
Author and reviewer in same session	Worktree isolation enforced: reviewer spawns in separate worktree, reads diff cold
Version v0.1.{sprint_number}	v0.{phase}.{n} tied to cascade phases
Sprint-close cleanup sweep	Pre-push clerk hook (automated) + milestone-boundary audit (manual)
Si (project manager) + Qatux (librarian) as separate agents	Merged into "clerk" agent — institutional guardrail
Sprint velocity tracking	WIP limits per work-type (max N tickets in_progress)

What dies:

• Sprint CLI (tooling/db/sprint)
• Sprint briefing files (docs/sprints/sprint-N/)
• Sprint-kickoff and sprint-close ceremonies
• The Si agent as a standalone personality
• Team-scoped file restrictions in CLAUDE.md

Personalities are not teams. Gestalt, Tyre, Paula, Burnelli-Sheldon, etc. survive as prompt-seeded divergence engines. They make pushback legible — when Jeroen sees a Burnelli-Sheldon objection he knows it's an economics concern, when he sees a Paula objection he knows it's a narrative/political concern. The personality is the signature, not a job description.

Worktrees are context firewalls, not team boundaries. Branches and worktrees survive — but their purpose changes from "team scope" to "context isolation." The reason a coding agent self-reviews its own PR is that it has all the context of writing the code. A reviewer spawned in a separate worktree physically cannot have that context — it reads the diff cold, which is exactly what a reviewer should do. The worktree enforces adversariality at the mechanism level, not the process level. This is an argument FOR keeping branch/worktree separation even after killing team-scoped restrictions.

---

Clerk Agent (Si + Qatux merge)

The team lead (interactive Claude session) optimizes for the user's current intent. This makes it structurally incapable of being the institutional guardrail — it will go along with whatever the user says in the moment, even if it contradicts a decision from three weeks ago.

The clerk is the separation of concerns between responsiveness (team lead) and institutional memory (clerk).

Pre-push hook implementation:

1. Pre-push hook spawns clerk agent with the diff
2. Agent checks D-record consistency, ticket drift, contradiction with active decisions
3. Agent writes findings to .cache/pre-push-review.md
4. Agent outputs exactly one word: APPROVED or REJECTED
5. Hook reads the word, exits 0 or 1
6. Timeout behavior: if agent doesn't respond within N seconds, automatic REJECTED. Agent keeps running in background — findings file arrives later. User reads it, decides whether to fix or force-push.

The findings file separates the agent's reasoning from its authority. Binary gate, verbose reasoning.

What the clerk checks:

• Changed files don't contradict active D-records
• Referenced decisions still exist
• Implementation doesn't drift from ticket intent (but ticket is descriptive, not prescriptive — drift is flagged, not blocked)
• Q-records relevant to changed files are surfaced

What the clerk does NOT do:

• Subjective code quality review (that's /pr-review)
• Sprint management (no sprints)
• Briefing maintenance (briefings replaced by live ticket queries)

---

Test Run Plan

Scope: The Tier 0/Tier 1 cascade work — all schema tables and Python importers from the planet-down-cascade workshop.

Milestone definition: "All schema tables and Python importers land on main. make regen-db produces a DB with heightmaps, city names, province boundaries, body_radius_km, normalized economic_role."

Rules for the test run:

• No sprint number assigned
• Topic branches per logical chunk (not team branches)
• Any agent personality can touch any file
• Tickets describe what needs doing, not how
• WIP limit: 3 tickets in_progress at once
• Milestone complete when all Tier 0 + Tier 1 tickets are done and verified

What we're measuring:

1. Did work flow or stall without sprint pressure?
2. Did removing file-scope restrictions cause chaos or remove friction?
3. Did tickets-as-description work, or did agents flail without prescriptive tickets?
4. Did anything get worse compared to Sprint 38's current state?

Rollback trigger: If after the test run the work feels less productive or less controlled than a sprint, Sprint 39 picks up where 38 left off. All sprint tooling remains in the codebase — dead code, not deleted code.

Parallel work (independent of test run outcome):

• Build the clerk pre-push hook — pure additive, helps regardless of process
• Can be tested against Sprint 38 pushes before the process switch

---

Risks

Risk	Mitigation
No natural "stop and audit" moment	Clerk pre-push hook + milestone-boundary manual audit
Work sprawl without sprint focus	WIP limits enforce focus; milestones enforce shipping
Losing the "signature" on who did what	Personalities preserved — commits and PRs still carry agent identity
Process change is a distraction from actual development	Test run uses real cascade work, not meta-work. Process change is the test.
Can't roll back cleanly	Sprint tooling stays in repo. Reversible.
Clerk agent too slow / too noisy	Timeout-reject for speed. Tune signal-to-noise over first milestone.

---

Decision Timeline

1. Now: Sprint 38 continues as-is
2. Sprint 38 close: Decision point — run test milestone or Sprint 39
3. During test milestone: Build clerk pre-push hook in parallel
4. Test milestone complete: Evaluate against measurement criteria
5. If positive: Write D-record confirming kanban + milestones. Kill sprint tooling.
6. If negative: Sprint 39. Revisit after more Claude Code harness fixes.

---

Related:

• feedback_broken_tests_not_preexisting_shield.md — pattern sprints may enable
• team-test.md — Claude Code harness test results (tmux teams partially broken v2.1.123)
• Epic #854 — pipeline discipline automation
• D-166 — cascade phases

---

Open count: 0.