Process Map: Block 3 Draft
Updated 2026-07-28. KG's intake answers arrived (2026-07-28-kg-intake-synthesis). They describe how she runs product development at Reffer, which is a different company building a conventional product with human developers and a QA function. They are input to this table, not a specification for it. Our design holds until we change it together. Her practice is recorded at the bottom for comparison, and the whole table is expected to change every sprint.
The function-to-platform table. Each row is a method we own; the columns show where it runs on each surface. The method column is canonical; the platform columns are swappable. Kristine's intake answers merge into the Jira column when they arrive; the live team session pressure-tests the whole table.
Function-to-platform table
| # | Method (ours) | GitHub primitive | Jira view | Who lives here |
|---|---|---|---|---|
| 1 | Feature specification (scope, outcome, intended user, IP value alone + compound) | Issue from a template with the four schema fields | Story/Epic description fields | Jonny writes or approves; KG leads |
| 2 | Requirements intake and pacing | Intake form → triaged issue | Intake queue | Diana |
| 3 | Prioritization and backlog | Milestones + labels. No GitHub Projects board in phase 1, because user-owned Projects do not survive the transfer to the ShurIQ org | Backlog ranking | KG with Jonny |
| 4 | Sprint planning | Milestone per sprint | Sprint (KG's native surface) | KG |
| 5 | Assignment and ownership | Issue assignee | Assignee | KG assigns; owners accept |
| 6 | Phase handoffs (concept → wireframe → design → execution) | Projects status columns | Workflow states | Alex ↔ Nicholas ↔ Jonny |
| 7 | Dependency and blocker tracking | Issue links ("blocked by") + task lists | Issue links + dependency view | Everyone; agent monitors |
| 8 | Progress visibility without interrupting anyone: who owns it, what is blocking it, when it lands | Issues filtered by milestone, assignee, and label | Board / timeline / Gantt | KG's stated core need |
| 9 | Code change | Branch per feature + pull request | Smart-commit links | Alex, Nicholas, Jonny |
| 10 | Review and merge gate | PR review, Jonny approves and merges | Status transition on merge | Jonny |
| 11 | Quality gates | Actions CI: grammar gate on report-producing branches, tests elsewhere | CI status on the ticket | Automated |
| 12 | Release and delivery | Tags + gated deploys (Cloudflare) | Versions / releases | Jonny |
| 13 | Unblock requests | Issue comment + label; Slack agent can approve PRs from Slack | Flags | Anyone; agent routes |
| 14 | Automation and agents | Claude Code agents with repo permissions (issues, PRs, branch ops) | Jira automation rules | Jonny configures |
| 15 | Cadence review and retro | Weekly sync against milestone view | Sprint report (burndown, velocity) | Whole team |
| 16 | Knowledge capture from dev work | Issue/PR history → OKF concepts → project knowledge graph | n/a (reads from GitHub) | Agent, weekly cadence |
Reading rules
- The method column never names a tool. If a method can only be described by naming Jira or GitHub, it isn't a method yet; decompose it until it is.
- GitHub is the system of record for rows 1-14. Jira renders views of that record. Where the two disagree, GitHub wins and the sync gets fixed, never hand-reconciled.
- Anyone can live in either surface. KG in Jira, Alex in GitHub, Nicholas in either: same work, two lenses. Nobody is required to learn the other's surface to participate.
- Row 16 is the compounding loop: development activity itself becomes knowledge-graph material, the same way client engagements do. The dev process feeds the same ontology as the product it builds.
Sprint-1 mechanics (ours, proposed for the team session)
These are our positions. They hold until the team changes them together.
- Sprint length: 1 week to match the existing weekly sync cadence. KG runs 2-week sprints at Reffer; discuss.
- Estimation: open. KG estimates in hours at Reffer. Note that hours do not describe work an agent fleet does overnight, so whatever we pick has to cover both human and agent-run work or apply only to the human part.
- Definition of ready: issue carries the four schema fields, a named owner, and its phase. KG's Reffer definition adds acceptance criteria, design direction, and identified dependencies, which is compatible and worth folding in.
- Definition of done: PR merged by Jonny, CI green, demo-able on the relevant surface, issue closed with the outcome noted against the stated intended outcome.
- The weekly sync stays the only standing meeting; everything else is async through the surfaces above.
- Everything here is v1. This table gets reviewed at the end of each sprint and is expected to change.
What our cycle has that a conventional product cycle does not
Worth naming before adopting any practice wholesale from another company, because these are the parts a human-sequential pipeline has no slot for.
- Work happens continuously without a ticket or an assignee. Twelve registered channels produce intelligence on their own cadence: the SBPI nightly at 06:13, the DKR heartbeat at 04:00, the Slack and Drive watcher continuously. None of that is anybody's ticket, and it does not appear on any board.
- Output is evaluated, not only tested. Some gates are deterministic and behave like QA (the grammar gate,
route-gate.py). Others are adversarial and probabilistic (the mega-eval, multi-agent verification). A single pass/fail QA stage does not model the second kind. - Nothing reaches a terminal "done." A route gets armed and is then watched. A recommendation compiles to a rule the nightly evaluator checks, and a TraceLink records whether the score actually moved in the weeks after. Standing coverage is the product, so "deployed and accepted, no further work expected" is not our end state.
- The feedback loop runs through an LLM. A change to an exposed prompt can alter output quality without any code changing, which means versioning and review have to cover prompts as first-class artifacts, not just source.
- Agents are also authors. Issues, specs, and route declarations get drafted by agents and reviewed by humans, so the review gates carry more weight than in a process where a human wrote everything first.
None of this makes a conventional pipeline wrong. It means the parts of it we adopt have to be extended rather than copied, and that is a conversation to have with KG rather than a decision to hand her.
KG's Reffer practice, for comparison (intake 2026-07-28)
Recorded so the team can weigh it. Not adopted. Full detail and her verbatim answers: 2026-07-28-kg-intake-synthesis.
| Topic | Her Reffer practice | Our current position |
|---|---|---|
| Stage ladder | Ten stages: Idea, To Do, Pending Development, In Development, Ready for Test, In Testing (with an Adjustments Needed rework loop), Ready for Deployment, For Reffer Review, Done | Four: concept, wireframe, design, execution. Ours needs extending for agent-run work, which hers does not cover either |
| Gates | Two: QA testing, then her product review before release | One: Jonny reviews and merges. We have no QA function |
| Sprint length | 2 weeks | 1 week, proposed |
| Estimation | Hours, preferred over story points | Open |
| Blockers | A blocked status plus a comment explaining how | Issue links and task lists. Hers is lighter and worth considering |
| Daily view | Backlog first, to check sprint progress and groom | Jira is her surface either way |
| Roadmap | Months ahead, re-groomed every 2 weeks | Milestones |
| Spec to ticket | "All of the above, it's a collaborative process" | Matches our intake method, where an agent drafts and a human approves |
| Ticket types | Not only engineering: research spikes, copywriting, design | Our registry is engineering-shaped and does not cover these. Genuine gap |
| Standing ceremony | A weekly or biweekly hour walking each ticket's intended outcome before work starts | We proposed async-only. Worth discussing |
Two of these are worth taking seriously on their merits rather than because she said them: non-engineering ticket types, since our intake method produces research and design work that has nowhere to be filed, and the intended-outcome review, which lines up with the intervention points already in the delivery grammar.
To decide together
- Sprint length and estimation, given that agent work is not measured in hours.
- Whether we want a QA stage and who would own it.
- Whether the intended-outcome review becomes a standing ceremony, and at what cadence.
- Ticket types for research, copywriting, and design in the feature registry layer key.
- Where the feature value schema lives. KG left this question unanswered; ask directly.
- Her Jira conventions and templates, pending a screenshot.
- Walking KG through items 1 to 5 in the section above, since her intake predates seeing how our cycle actually runs.