# Keep Git: shared answers about change

One continuous illustrative payment-change story. Speech estimates use 150 words per minute; no recorded narration or synchronized captions are claimed.

| # | id | ~sec (est, speech only) | words | narration | on-screen text |
|---|---|---:|---:|---|---|
| 1 | orient | 18.80 | 47 | Anthropic built Scion to handle a source-control workload most teams have never faced. Its agents and jobs needed answers about code without repeatedly acquiring a working copy. We can borrow that idea while keeping Git, GitHub and GitLab. The useful question is what our agents keep reconstructing. | Keep Git. Share the answers. |
| 2 | pressure | 19.20 | 48 | Our workflow merged around fifty pull requests a day over the last month, including code, documentation and verification. We encountered throttled review reads and a publication check that judged the wrong commits. Those incidents point toward the answers agents act on. They do not prove Git needs replacing. | Find the pressure in your workflow. |
| 3 | payment | 19.20 | 48 | Consider an illustrative payment change. Before proceeding, an agent needs to know which components it affects, which checks apply and whether the required review exists. Git records the source. GitHub or GitLab records reviews and checks. Someone must connect those facts. Several agents may each repeat that work. | Follow one payment change. |
| 4 | shared | 21.20 | 53 | Start by making that recurring question directly answerable. A library or an existing coordinator may be enough. Share observations and coordinate forge refreshes. If a refresh fails, say the answer is unknown. A failed read must never tell the next agent that no review is waiting. But sharing observations is only the beginning. | Answer the question once. |
| 5 | relationships | 22.00 | 55 | The payment change touches settlement and a shared serialization library. An impact analysis connects them to the relevant checks. Let the next agent reuse that reasoning, with the source, dependencies and policy it used. Scion derives indexes from immutable revisions. Applying that pattern to impact and verification is our proposal, not a demonstrated Scion capability. | Keep the reasoning with its inputs. |
| 6 | policy | 24.00 | 60 | Suppose the team tightens its payment policy while the patch stays unchanged. The old analysis still records its original conclusion, but the required review may differ. Recompute the answer under the new policy, keeping the old result. Start with recommendations while normal checks continue, because the relationships you have recorded may be incomplete. Now let the surrounding code change too. | Unchanged code can need a new answer. |
| 7 | moving | 21.60 | 54 | A new version of the shared library lands while the payment review waits. The earlier settlement test really passed with the old version. Preserve that result. It does not automatically certify the new combination. The next reviewer needs a specific answer: check settlement against the new library before treating the payment change as ready. | The patch waits. Its library moves. |
| 8 | action | 24.40 | 61 | When that check passes, record the payment and library revisions it tested. Before publishing a review, identify the revision being approved. Carry it into GitHub or GitLab’s operation where supported. A separate publication repair taught us to establish the actual destination history and carry the checked source through publication. Provider controls differ; a fresh read alone cannot eliminate a concurrent change. | Carry the checked version into the action. |
| 9 | alternative | 20.80 | 52 | This does not require a new shared service. Ordinary Git, reliable checks and disciplined scripts may already answer the question at lower cost. Sharing creates maintenance, availability and credential responsibilities. We have added opt-in local performance logging, but its coverage is partial. It lets us begin measuring; it does not establish savings. | The simplest approach may be enough. |
| 10 | trial | 22.80 | 57 | Try the payment question alongside the normal workflow. Compare repeated work and waiting for the same class of change, including the cost of maintaining the shared answer. A missed component or an obsolete policy is a failed trial, even if requests fall. Keep the improvement only if its saved effort earns that cost and decisions remain dependable. | Try one bounded question. |
| 11 | close | 18.40 | 46 | If repository transfer and maintenance dominate, investigate hosting or source-control changes on that evidence. Otherwise, improve the answers agents keep reconstructing. Git can record the code. The workflow around it should explain what the change affects and whether the available evidence still supports the next step. | Let your workload decide. |

## Sources and scope

Scion is a reported precedent. Payment changes are illustrative. The shared impact/verification approach is a proposal, with no measured savings. Our incidents and partial logging are documented in the companion article.

[Anthropic’s account](https://www.anthropic.com/engineering/redesigning-source-control), [GitHub guidance](https://docs.github.com/en/rest/using-the-rest-api/best-practices-for-using-the-rest-api), [publication repair](https://github.com/medici-finance/assay/pull/2676), [logging implementation](https://github.com/medici-finance/assay/pull/2853).