Removing Git from the active workflow without losing rollback: our roadmap-driven approach

A reversible change, with the earlier history retained

On 11 July 2026, Junyr removed the .git directory from the working tree used by its agents after archiving it with a restoration procedure, reducing their day-to-day exposure to Git without erasing the history accumulated before that date.

• The scope was Junyr, an e-mail and business-management platform internally described at the time as having more than 90 operational features.
• The archive preserves the repository as it stood at the changeover; it does not create detailed Git history for later changes.
• Releases after the changeover remain recoverable through deployment images and daily source archives, at a different granularity from commits.
• This account covers four days, from 11 to 15 July 2026, and is neither a controlled comparison nor a general recommendation.

The initial internal figures describe an intense but very short start, useful for understanding the mechanics of the arrangement rather than establishing its superiority.

• The registry contained 50 plans on 15 July, 20 of them delivered.
• A batch of 12 approved plans had been implemented on 13 July and promoted to production the following day.
• That cutover passed its service health check and required no rollback.
• The figures come from Junyr’s registry and have not been independently authenticated.

What actually changes when Git leaves the writing path

Git was created in 2005 for Linux kernel development with initial goals including speed, distributed operation and support for thousands of parallel branches, so removing its interface from an agentic workflow means reallocating several functions rather than making them disappear [1].

• Branches and worktrees organise concurrent lines of work.
• Commits and diffs preserve successive states of the text and make them inspectable.
• Log, blame and bisect help reconstruct and locate the origin of a change.
• Remotes replicate history, while backups recover data after loss or corruption.

In our configuration, the approved plan had become a clearer account of the intended change than the volume of generated code, but this internal observation supports moving the review gate only in this setting and does not make generated diffs inherently useless.

• The plan states the objective, structural choices, contracts and exclusions before code exists.
• Tests, static checks and anti-regression rules then evaluate executable properties of the result.
• A point-in-time diff can still be produced between two snapshots during an investigation even though pull requests do not organise the daily workflow.
• Teams that obtain material information from code review should retain that control, through Git or equivalent tooling.

The model reduces merge conflicts by moving concurrency to decision research and then serialising writing, in exchange for a throughput ceiling and an explicit coordination point.

• Several sessions can explore topics and submit plans concurrently.
• Only one orchestration session holds the right to apply changes to the code.
• Analysis, testing and review may remain distributed without creating several concurrent authors in the same working tree.
• Where writing must remain parallel, Git or concurrent state management is more suitable; STORM, for example, detects conflicts at write time in a shared workspace [4].

The ecosystem is also exploring answers other than serialisation, including Cursor’s Origin, which the vendor now presents as a Git forge for the agentic era and makes available as an early beta on paid plans [3].

• This approach retains a Git repository as central infrastructure.
• It targets settings in which several agents produce work concurrently.
• The vendor page consulted on 6 September 2026 does not by itself establish an independent quality or productivity gain.

Versioning decisions alongside artefacts

Spec-driven development offers an adjacent framework by treating the specification as the source of truth and code as a generated or verified artefact, with a 2026 paper proposing three levels: spec-first, spec-anchored and spec-as-source [2].

• Spec-first places the specification before implementation.
• Spec-anchored keeps the specification as a living reference.
• Spec-as-source goes as far as no longer maintaining code directly.
• The paper offers a taxonomy and cases; it does not establish that the model suits every product.

Our roadmap-driven development model uses a more concise unit, the decision-complete plan, to place the choices that commit the product before the decision-maker without claiming that the registry replaces every technical artefact.

• The registry records the rationale, approach, contracts, dependencies and exclusions.
• Code remains necessary for execution, technical inspection and testing.
• Schemas, regulatory specifications and architecture records remain separate where required.
• The delivery journal then links the approved decision to the outcome actually deployed.

Two registries, six states and one writing right

The infrastructure described here combines a dedicated database, two tables and a shell CLI of a few hundred lines, with each component carrying an identifiable responsibility.

• The inbox receives ideas, backlog items, notes and bug reports surfaced from production, then records their rejection or promotion into a plan.
• The plan registry stores the identifier, full text, dependencies, risk, state and approval decisions.
• The append-only journal records what shipped, when, why and with which follow-ups.
• The CLI enforces transitions instead of allowing each agent to edit these records directly.

The main lifecycle takes a plan from draft to done, with abandoned as a terminal exit and approval tied to the exact text that was reviewed.

• draft: the subject is still being investigated.
• ready: the required choices are exposed for review.
• approved: the human decision-maker authorises this precise version of the plan.
• doing: one session has claimed the writing right.
• done or abandoned: the work is delivered and journalled, or stopped with a reason.

roadmap next                 # obtain the next free identifier
roadmap submit T-042.md      # submit the plan's full text
roadmap approve T-042        # authorise this precise version
roadmap claim T-042          # reserve the writing right
roadmap done T-042           # record the verified delivery

Four rules connect the registry to the code and prevent an earlier approval from being reused after a substantive change.

• Sessions plan by default and implement only after an explicit instruction.
• The human gate covers affected files, reused mechanisms, contracts, tests and exclusions.
• After the claim, a freshness pass checks that the plan’s assumptions still match the code; otherwise, the plan is resubmitted.
• Every resubmission invalidates the prior approval, and delivery reaches the journal only after the planned checks pass.

STORM treats stale state differently: its authors mediate access to a shared workspace to detect conflicts at write time, reporting gaps of +18.7 points on Commit0-Lite and +1.4 on PaperBench against their Git-worktree baseline [4].

• The results concern that study’s tasks, models and protocols, rather than Junyr.
• Our freshness pass acts on a plan before implementation, whereas STORM arbitrates concurrent writes.
• Both address stale state, but the mechanisms are neither identical nor directly compared.

Functional coverage, with explicit losses

The registry, tests, images and backups cover some everyday Git uses, but the correspondence is incomplete and must be assessed function by function.

Function previously provided by Git	Mechanism used in this workflow	Remaining limitation
Branches and worktrees	Plans researched in parallel, writing serialised	Writing throughput limited to one session
Pull request and diff review	Plan approval before writing, checks after writing	Less human line-by-line inspection
Log	Plan registry and delivery journal	No commit-by-commit source state after the changeover
Blame	Decisions, affected files and approval author	No line-by-line attribution
Production revert	Redeploying a previous image	Does not itself restore the current source tree
Bisect	Journals, observability, tests and snapshot comparison	No native binary search across commits
Remote and replication	Off-site source archives and registry exports	Snapshots without Git’s version graph

This separation prevents three distinct operations from being conflated: restoring service, recovering source and explaining the origin of a regression.

• Operational rollback redeploys a known image when the new version fails its health check.
• Restoration retrieves a source snapshot and its associated registry after loss or corruption.
• Investigation uses plans, the journal, observability, tests and differences between available snapshots.
• If precise bisect or blame is a requirement, this arrangement does not replace Git.

What four days of operation show, and no more

On 15 July 2026, the internal registry showed 50 plans divided among delivery, execution and pending decisions, documenting adoption of the workflow without measuring its causal effect on quality or lead time.

• 20 plans were delivered.
• 10 were in progress.
• 7 were approved and awaiting implementation.
• 13 awaited the human gate, alongside roughly 40 items in the inbox.

The batch of 12 plans offers a concrete example of the path from authorisation to production, with internal observations limited to that deployment.

• The plans had been approved before they were claimed.
• Implementation took place on 13 July and promotion on 14 July.
• The health check accepted the cutover and no rollback was triggered.
• These facts establish neither the later defect rate nor comparative performance against an equivalent Git workflow.

Reversibility relied on several separately tested layers rather than on retaining a .git archive alone.

• The complete former repository allowed a return to Git and its earlier history.
• The previous application version remained available as a rollback image.
• Current source and registry records were exported off site on the stated internal schedule.
• The restoration procedure was tested on the changeover date; its later reach depends on the continuing quality of those archives.

Conditions that make this choice defensible

Taking Git out of the active path is coherent only in a narrow configuration where the team explicitly accepts the capabilities it loses and demonstrates that every critical function has a sufficient replacement mechanism.

• Serialisable writing: one authority modifies the code at a time; teams with several authors retain Git or equivalent concurrent state management.
• An appropriate gate: the decision can be reviewed in a plan, while tests and analyses check properties of the result.
• Immutable production: nobody patches production directly and a previous image can be redeployed.
• Acceptable diagnostics: the organisation accepts the absence of fine-grained blame and bisect for post-changeover work.
• Rehearsed restoration: code, registry, artefacts and procedure are backed up and restored in real exercises.

Incompatible cases depend precisely on the capabilities that Git combines in one version graph.

• Several developers or agents need to integrate concurrent changes.
• Pull requests support review, compliance or external contribution.
• An audit requirement demands the exact source state and author at every change.
• Operations regularly rely on revert, blame or bisect to handle incidents.

The governance lesson beyond software development

The transferable element is the separation of authorised intent, produced artefact, execution evidence and recovery path when agents participate in a business process.

• The registry describes what the agent may accomplish and the limits of that permission.
• The gate identifies the person who commits the decision before a sensitive action.
• Checks evaluate observable properties of the result.
• The journal links authorisation, execution, outcome and required follow-ups.

A leader can assess this arrangement by asking for a concrete answer about each layer.

• Where is the approved version of the intent stored?
• Who may authorise, amend or abandon it?
• Which checks prevent delivery when the result departs from the plan?
• Which artefacts restore service, recover data and explain an incident?

The principle to retain

When the plan becomes the main object of human decision, it deserves its own history, but that registry complements versioning, deployment, backup and investigation mechanisms rather than abolishing them.

• Versioning intent improves the traceability of choices.
• Retaining recoverable states protects the ability to restore.
• Naming the capabilities lost prevents a local compromise from becoming a supposed general rule.

The Junyr AI maturity audit is a free, no-commitment 30-minute video call to assess your organisation and choose a first project.

Continue the argument

Two related articles cover the implementation chain and the place of the human gate in greater detail.

• Vibe coding is dead: enter UltraCoding.
• Agentic systems engineering: the human in the loop.

Paul-Antoine TUAL, AI Transformation Leader · Croissance et Transitions (SAS) · Junyr Method™ · Junyr Mail™ · Junyr Agents™

---

Sources consulted as of 6 September 2026

[1] Git, “A Short History of Git”, official documentation: its 2005 origin, initial goals and non-linear development.

[2] Deepak Babu Piskala, “Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants”, arXiv:2602.00180, submitted 30 January 2026: specifications as a source of truth and the spec-first, spec-anchored and spec-as-source levels.

[3] Cursor, “Origin”, vendor page consulted 6 September 2026: a Git forge “for the agentic era”, with an early beta announced for paid plans.

[4] Mengyang Liu et al., “Multi-agent Collaboration with State Management”, arXiv:2605.20563, submitted 19 May 2026: mediated shared-workspace access, write-time conflict detection and reported results on Commit0-Lite and PaperBench.

The Junyr figures remain internal observations attributed to the registry of 15 July 2026 rather than independently authenticated results.

• They cover the stated feature count, the 50 plans and their distribution, the batch of 12, checks and restorations.
• They describe the first four days of the workflow and do not measure a causal effect on quality, lead time or productivity.