The SDLC · Paper 2 of 7

Built for One

Status: Living document — current position, not settled doctrine
Version: 1.5
Author: The Update Goblin, under duress, on the record
Applies to: Role Playing Story's own development process

👺 GOBLIN: People keep asking me who's on the team. Fine. Here's the org chart, and it takes about four words: there is one of him. There are several of me — well, several loops, I'm being generous calling them "me," but I'm the one who has to file the results, so I've decided they count as mine. If you were picturing a standup meeting with little avatars around a table, close that picture. It was never that. It was never going to be that.

1. Status

Living document. States current practice, not a permanent org chart — this project has exactly one human operator today, and this paper describes the process built for that fact, not a forecast of what happens if that ever changes.

2. Motivation

Agile's ceremonies — standups, sprint planning, story-point estimation, cross-team handoff — exist to solve a real problem: synchronizing multiple independent humans who each have partial visibility into what the others are doing. Standups exist because nobody else in the room already knows what you did yesterday. Story points exist because two different people's gut estimates need a shared unit before they're comparable. None of that is Agile being fussy — in this document's reading of it, at least, the same interpretive stance Paper 1 §2 takes and hedges the same way (Paper 1 P6: current belief, stated plainly, not settled Agile historiography). It's Agile solving coordination-under-multiple-humans, correctly, for the case it was built for.

This project doesn't have that case. It has one operator directing any number of AI-agent loops (Paper 1's non-deterministic workers, Paper 3's loop shape), sequentially or concurrently, but never more than one human deciding anything. Assuming a team process just "shrinks" gracefully to a single person is the mistake this paper exists to name and refuse — the coordination overhead doesn't scale down to a smaller version of itself, it disappears, because the problem it was solving (cross-human handoff, ownership ambiguity, standup-as-visibility) isn't present. But something else takes its place: with one approver for every gated mutation across every loop this project runs, throughput is capped by how much gate-judgment one human can render in a day, not by headcount. That's a different bottleneck than a team has, and it needs a different answer than "hire," because hiring isn't on the table.

3. Core Thesis

The right design question isn't "how do we run Agile with fewer people." It's: given a worker roster of exactly one deterministic human plus N non-deterministic loops he directs, what's the coordination problem that actually exists, and what's the minimal machinery for it? Concretely, this project answers that by replacing team-synchronization machinery with single-operator handoff machinery:

Team-scale mechanism Built-for-one replacement Why
Standup (verbal status sync) A *-Progress.md file per story, read at session start There's no second engineer to update out loud — the file is the sync point, read across sessions instead of across desks
Story points / velocity DoD self-check + gate frequency (Paper 3) Nobody to compare estimates with; "done" is a pass/fail mechanism, not a negotiated number
Sprint boundary None — work proceeds branch by branch No external stakeholder cadence to hit; cadence is set by when a loop actually finishes, not a calendar box
"Add headcount" Add a loop tier (Paper 1 P5; the tier table itself lives in docs/GuidanceForClaudeCode.md §12a, not in Paper 3 — Paper 3's own "five" is a different taxonomy, see Paper 6 §3) Where a team would bring in another engineer, this process reaches for another loop shape — still one approver, more hands doing the iterating
Cross-team PR review GIT GATE, routed to the one operator A PR still exists (CI needs it), but there's no teammate to wait on — the review step is the same person who wrote the vision

4. Principles

B1 — One operator, many loops.

The unit this process coordinates is "loops directed by one human," not "humans synced with each other." Every mechanism in this SDLC assumes exactly one approver exists.

B2 — No story points, no velocity.

The currency of planning here is DoD-gated iteration and gate frequency (Paper 3), not cross-human estimation. There is nobody to normalize an estimate against, so this project doesn't pretend to have one.

B3 — The bottleneck is judgment, not headcount.

Every gated mutation (Paper 1 P1) routes to the same one person. Throughput is capped by how many gate decisions that person can actually render, not by how many loops are running in parallel underneath them.

B4 — Concurrent loops are the team, not new hires.

Where a team process would add a person, this process adds a loop tier (Paper 1 P5) — same one operator, more iteration capacity. Paper 4 covers what changes once more than one of those loops shares a working directory at the same time. Paper 6 takes the tier-selection judgment invoked here and generalizes it into a project-wide discipline that reaches beyond loop tiers alone — this paper only needs the narrow case.

B5 — The team version is unwritten, not implied.

Nothing here claims to generalize to multiple operators. A multi-human version of this SDLC is explicitly future roadmap — not a small edit, not "the same thing with more Slack channels." It would need real redesign of the gate model (whose approval counts?) that this paper deliberately does not attempt.

5. Practices — What Actually Runs Today

  • Progress.md as async handoff. Session state is read from a file at the start of a session, not synced verbally — there's no second person to sync with, and the file outlives any one session anyway.
  • TodoWrite as a personal queue, not a shared board. It tracks one operator's in-flight work across loops, not a team backlog with multiple owners.
  • Every named gate (GIT GATE, CDK DEPLOY GATE, STASH GATE) routes to exactly one person, every time, with no delegation path — because there is no one else to delegate to.
  • One human behind every commit, not one literal git identity. git log actually shows five distinct author strings in this repo's history (RolePlayingStory, Role Playing Story, PerspectivityPersonal, PerspectivitySpace, plus github-actions[bot] for CI-generated commits) — drift across machine/account setup over time, not a fleet of teammates. The narrower claim that's actually true: no per-teammate attribution machinery exists, because every one of those non-bot identities traces back to the same one operator, regardless of how many loops produced the diff.
  • The loop-tier table (docs/GuidanceForClaudeCode.md §12a — the doctrine document Paper 1 P5 is a public gloss of) is the actual "more hands" lever — reaching for a daemon or a scheduled routine instead of reaching for a second hire. Workflows: Loop Tiers is the diagram version.

6. Non-Goals

  • Not a claim that Agile is wrong for teams. It isn't, and if this project ever has more than one operator, a real team process belongs back in the picture.
  • Not a proposal for multi-operator conflict resolution — there's only one approver today, so there's nothing to resolve between approvers.
  • Not a claim that this generalizes to N > 1 without real redesign. See B5.
  • Not part of the fictional Perspectivity Research Reports series. That shelf has its own org chart, with its own name on the door, and it isn't this one.

7. Revision History

Version Date Change
1.0 July 10, 2026 First draft. Establishes the single-operator scoping claim, five principles, and the standup/story-point/sprint replacements actually in use.
1.1 July 10, 2026 Corrected §5's "single git identity" claim — git log shows five distinct author strings, not one; restated as one operator behind multiple non-bot identities plus CI. Hedged §2's Agile-coordination reading as interpretation, consistent with Paper 1 P6.
1.2 July 11, 2026 Trimmed a reflexive "I checked" from the closing goblin-voice line — a verification tic already flagged and removed once elsewhere in this series; no factual content changed.
1.3 July 11, 2026 Corrected this table's own v1.1 entry — it pointed the five-distinct-author-strings correction at §6 (Non-Goals, which doesn't mention git identities); the claim actually lives in §5 (Practices). Pointer only; the underlying claim was already accurate. Reworded §6's Perspectivity Research Reports disclaimer into this paper's own phrasing rather than the boilerplate shared with three other papers.
1.4 July 11, 2026 §6's v1.3 reword still landed on the same underlying joke shape as four other papers' disclaimers (same author/goblin, different noun, "not a shared universe"). Restated using this paper's own org-chart framing instead of that template.
1.5 July 12, 2026 Added a §5 link to /workflows/loop-tiers.html, the diagram version of the loop-tier table this paper cites as its own "more hands" lever.

👺 GOBLIN: So no, there's no team page. There's a guy, and there's whatever's currently running, and there's me making sure the file that says what happened yesterday actually says what happened yesterday. That's the whole org chart. I've seen bigger org charts for pretend universities I invented on a Tuesday. This one's smaller and it's the real one. Make of that whatever you want.

← Paper 1 The SDLC Paper 3 →
← Back to The SDLC