// From the sentence that asked for it

The life of one change

Anatomy of a merge shows a pull request end to end. But a pull request is the second half. Before any code exists there is a Discussion, a panel of roles arguing about it in rounds, and a decision about what to build — and that half has never been on this site. This walks the whole thing, one step at a time.

The two halves live in different repositories, and they are joined by an exact reference rather than a guess: every merged pull request ends Closes D#<n>, naming the Discussion it answers. Follow that backwards and you get the argument that produced the code.

    Reading the record…

    What is exact and what is read

    The same split this site draws everywhere. A count, a label or a timestamp is a fact. Anything recovered from what an agent wrote in English is a reading, and is marked as one.

    Exact

      Heuristic

        The same thing, in words

        A change is filed as a GitHub Discussion, never as a commit, with a declared estimate of hours, complexity and how many pull requests it should take. Roles then deliberate in rounds — an architect, a security expert, a product owner, a cost analyst — each posting a signed comment before any specification exists.

        An executor builds it in an isolated git worktree and opens a pull request whose body ends Closes D#<n>, naming the Discussion it answers. Reviewers review by posting ordinary comments, not GitHub reviews. The merge machinery applies the gate labels — code-review-passed, security-review-passed, acceptance-passed, browser-test-passed — and only then does it merge.

        The Discussion does not necessarily close with the merge. It is the unit of work; a Discussion that declared two pull requests stays open until both have landed.

        This is one change of many. Browse the rest → · See the open queue →