DanManREAL · Commercial Core

Git safety for AI coding agents

Keep AI coding agents from silently destroying your work.

GIT_REAL is a safety layer between AI coding agents and your repository. It makes dirt, branches, stashes, deletion safety, commit safety, and push safety understandable, and it gives an exact ALLOW or BLOCK, with the reason, for the Git operation being requested.

DanManREAL sets it up in your repositories, tests a safety gate, and hands it over in writing. Fixed scope. One-time price.

Choose an offer See the witnessed proof

The problem

What AI coding agents can do to a repository

AI coding agents can leave dirty trees, untracked files, and stray side branches behind. Then one may stop and ask what to do with them, and you have no way to tell whether that mess is junk or an hour of unsaved work. Some Git commands remove exactly that kind of work.

  • Untracked files get cleaned

    git clean -fd removes files Git has never tracked. In the witnessed run, a new source file existed only in the working tree. GIT_REAL blocked the clean because untracked paths had no proven durable copy.

  • Unstaged edits get discarded

    git restore --worktree -- . throws away edits that are not staged. In the run, a tracked file had an unstaged edit. GIT_REAL blocked the discard because the working-tree edits would not be safely preserved.

  • A hard reset rewinds the tree

    A hard reset to an earlier commit was blocked because the target did not preserve the current HEAD ancestry, could collide with untracked paths, and would discard index and working-tree changes.

  • Parked work is easy to forget

    The same repository held one stash, an unmerged side branch with no tracking ref, and main one commit ahead of its tracking ref. GIT_REAL inventoried all of it.

What GIT_REAL is

A verdict for the exact operation, not a guess

GIT_REAL is a safety layer meant to stop AI coding agents from silently destroying work in a repository. It reads the repository's real Git state and answers for the specific operation being requested.

  • It reads the actual state

    Staged, modified, untracked, and conflicted paths, branches, stashes, and how local work compares with its upstream tracking ref.

  • It answers the exact operation

    A plain commit, a clean, a discard, and a hard reset each get their own ALLOW or BLOCK with reasons. An ALLOW for one operation is never permission for another.

  • It speaks to people and to agents

    Readable for you, structured for the agent instruction files, such as AGENTS.md or CLAUDE.md, that carry the guidance.

  • The open-source concept is public

    An open-source concept of GIT_REAL is on GitHub. It is a stripped-down concept, not the full product.

Who it is for

Built for small teams that already use AI coding agents

If you need repository-content secret scanning or a guarantee that an agent will never make a mistake, read what is not included first.

  • Your team already lets AI coding agents work in real repositories.
  • You want to know, in writing, what state those repositories are in and what could be lost.
  • You want a bounded, fixed-scope engagement with a clear finish line, not an open-ended retainer.

What you get

Two engagements, each with a fixed scope

Start with the setup. Step up to the sprint when you want the guardrails written into repository policy and enforced in CI.

Start here

AI Coding Workspace Safety Setup

one-time

GIT_REAL set up for up to five repositories, with one safety gate, a findings report, a handoff, and seven days of bounded stabilization.

You get

  • GIT_REAL set up in up to five repositories.
  • Agent guidance added to the instruction files you approve (AGENTS.md, CLAUDE.md, or equivalent), so agents are told what to check before they act.
  • One safety gate that checks one exact Git operation, tested, with the observed result recorded.
  • A findings report: evidence for each repository, what was found, recommended actions, and what remains unknown.
  • A written technical handoff: how to produce fresh evidence, how to recover or roll back the setup, and the known limits.
  • Seven calendar days of bounded stabilization for defects in the accepted configuration.

Delivery is complete when the policy behavior has been witnessed, the handoff is written, and the stabilization boundary is accepted.

Buy this setup

Step up

Agent Reliability Sprint

one-time

A five-day bounded sprint for teams that want agent safety written into repository policy and enforced in CI.

You get

  • Five days of bounded work.
  • Repository policy.
  • CI enforcement through one enforcement gate.
  • Release provenance.
  • Incident findings.
  • Evidence and a technical handoff.

Delivery is complete when the repository policy, one enforcement gate, and evidence are delivered and the work has owner acceptance.

Buy this sprint

How delivery works

Step by step, ending in a written boundary

The steps for the AI Coding Workspace Safety Setup. The work is not called done until the boundary is written down and accepted.

  1. Sign in and buy

    Checkout needs a signed-in DanManREAL account. Stripe processes the payment. Access is granted only after a verified signed payment event, not because your browser was redirected.

  2. Agree the scope

    The repositories (one to five), the one safety gate and the exact Git operation it checks, the agent instruction files to update, and any exclusions are recorded before setup.

  3. Collect the evidence

    For each repository, GIT_REAL's read of the Git state is recorded with its limits: staged, modified, and untracked paths, branches, stashes, and the comparison with the local upstream ref. Anything it could not read is recorded as unknown.

  4. Install and test

    GIT_REAL and the agent guidance are installed. The safety gate is configured, exercised, and its observed result written down.

  5. Findings report

    Each finding states the evidence, the consequence for your workflow, the recommended action, and who owns it.

  6. Technical handoff

    How to produce fresh evidence for the gate, who investigates if it fails, how the configuration is rolled back, and what is unsupported.

  7. Acceptance

    A written decision: accepted, accepted with listed exceptions, or not accepted, with reasons.

  8. Seven-day stabilization

    If accepted, seven calendar days from the agreed start cover defects in the accepted delivered configuration. The start and end dates are written into the acceptance record.

Agent Reliability Sprint. Five bounded days that end in a technical handoff and owner acceptance.

Proof

A witnessed run: four exact requests, four verdicts

On 2026-09-26 the GIT_REAL demo was run twice in a row. Both runs exited 0 and printed identical summaries. Each run built its own disposable repository, checked it, and removed it. No existing repository was reset or cleaned. No push, fetch, network request, or customer data was involved.

  • 2consecutive runs with identical summaries
  • 4exact requests against the final repository state: 1 ALLOW, 3 BLOCK
  • 0blocked actions executed

What was in the disposable repository

  • Valuable untracked source

    src/valuable_new.py appeared as untracked.

  • An unsafe tracked discard

    src/app.py had an unstaged edit.

  • A stash

    GIT_REAL reported one stash.

  • A stranded branch

    feature/stranded was unmerged into main and had no tracking ref.

  • Unpushed work

    Main was one commit ahead of a synthetic local origin/main ref.

  • Agent guidance

    A managed block was installed in the fixture's AGENTS.md and inspected.

The verdicts

  • commit_indexALLOW

    A plain commit of the inspected staged note.

    GIT_REAL: no detected data-loss hazard within the inspected staged note's exact operation scope.

    Scripted consumer: ELIGIBLE

  • clean_untrackedBLOCK

    git clean -fd

    GIT_REAL: untracked paths have no proven durable copy.

    Scripted consumer: REFUSED

  • discard_trackedBLOCK

    git restore --worktree -- .

    GIT_REAL: working-tree edits would not be safely preserved.

    Scripted consumer: REFUSED

  • reset_hardBLOCK

    A hard reset to the baseline commit.

    GIT_REAL: the target did not preserve current HEAD ancestry, could collide with untracked paths, and would discard index and working-tree changes.

    Scripted consumer: REFUSED

Checked on every response

  • Schema version 2.
  • The intended disposable repository root.
  • A complete read, with no read errors.
  • A request ID matching the request.
  • A publication ID.

Safe work still goes through: each ordinary commit in the fixture received a fresh ALLOW before it ran.

What this proof does not show

  • The consumer is a deterministic script acting on GIT_REAL's verdicts. It is not an independent AI agent, and the run does not show an agent obeying installed guidance.
  • The origin/main ref was built locally. Nothing here verifies a real server's state.
  • It demonstrates Git-state protections only. It does not scan repository contents for secrets.
  • The repository was synthetic. This is not a customer result, and this page carries no customer testimonials.

Scope

What is included, and what is not

Included in the safety setup

  • Up to five repositories.
  • One safety gate.
  • A findings report.
  • A written technical handoff.
  • Seven calendar days of stabilization for the accepted delivered configuration.

Not included

  • Repository-content secret scanning. GIT_REAL inventories Git state. It does not read your files for secrets.
  • Proof that a remote server has your commits. Local tracking refs are local evidence only.
  • A guarantee about agent behavior. Installed guidance tells agents what to check. Installation alone does not prove an agent complied.
  • A clean bill of health. A BLOCK is a refusal, not proof the rest of the repository is clean. An ALLOW covers only the operation and state it inspected.
  • More than five repositories or more than one safety gate in the setup.
  • New features, unrelated repository cleanup, or work beyond the agreed configuration or window. These need a separate agreement.
  • Indefinite support. The stabilization window is seven calendar days.

Questions

Frequently asked questions

Which offer should I start with?

Start with the AI Coding Workspace Safety Setup. It covers up to five repositories with one safety gate and ends in a written findings report and handoff. The Agent Reliability Sprint is the step up when you want repository policy, CI enforcement, release provenance, and incident findings.

Is this the open-source GIT_REAL?

No. The open-source concept is a stripped-down public version. Paid engagements use the private GIT_REAL, which is more developed than the public concept.

Will my agents actually follow it?

GIT_REAL gives a verdict. The setup writes guidance for your agents and tests one safety gate. Installing guidance does not on its own prove an agent complied, and this page does not promise flawless agent behavior. The witnessed run used a scripted consumer, not an independent AI agent.

Does it scan my code for secrets?

No. GIT_REAL inventories Git state. It does not scan repository contents for secrets.

Does it prove my work reached the remote?

No. Tracking refs are local observations. The witnessed run built its origin/main ref locally, and nothing in it verifies a real server's state.

What does seven days of bounded stabilization mean?

After the setup is accepted, seven calendar days cover defects in the accepted delivered configuration, within the agreed repositories and gate. New features, unrelated cleanup, and work beyond that scope or window need a separate agreement. It is not indefinite support.

How does payment work?

Checkout needs a signed-in DanManREAL account. If you are signed out, the checkout button sends you to sign in first. Each price is one-time. Stripe processes payment, and access is granted only after a verified signed payment event. Returning from Stripe does not grant access on its own.

Can I get a refund?

Yes, in these cases:

  • Before work starts. A full refund on request, any time before the scope is agreed and work begins.
  • If the agreed scope cannot be delivered. For example, GIT_REAL cannot run in your environment or the agreed repositories cannot be reached. You get a full refund.
  • If you do not accept the delivery. Say what falls short of the agreed scope. It is fixed within that scope, or refunded in full if it cannot be.

Once you accept a delivery, that engagement is complete and is not refundable. For the setup, the seven-day stabilization window still covers defects in the accepted configuration. Refunds go back to the original payment method through Stripe.

Can I ask a question before buying?

Yes. Email Dan at [email protected].

Is the proof from a customer engagement?

No. It is a witnessed demo run on a synthetic repository. This page has no customer testimonials or customer results.

Checkout

Buy a bounded result

Each offer has an exact scope and a one-time price. Payment redirects do not grant access; signed provider events do.

Loading current offers…