The Repo Gets the Decision

Over the past few weeks, we rebuilt Pathmode around a repo-native center of gravity.

Previously, we treated the repository as a destination for product intent. That was backwards.

The repository is where the agent works. The intent should live there too.

So intent.md is now the authority. Agents can create, challenge, hand off, and verify it inside their normal workflow. We also built an open IntentSpec standard, deterministic conformance, an OpenSpec bridge, and a way to bring an existing repo intent into Pathmode without rewriting it.

Pathmode does not replace the repo. Its job is what a file alone cannot do: keep private customer evidence out of git, provide a door for attributed human judgment, and eventually detect when evidence changes undermine decisions spread across repositories.

The repo gets the decision. Pathmode keeps the evidence and judgment behind it.

This is a conviction bet, not a victory lap. We will not measure it by installs, pageviews, or MCP launches. We will measure whether real repositories repeatedly use intent in agent work across distinct weeks.

We had the architecture backwards

The old model put the product workspace in the middle.

A team would shape a decision somewhere else, then export or hand it off when implementation began. The product tool was the center of the workflow. The repository was one of several delivery channels at the edge.

Coding agents do not work that way.

They begin in the repository. They read its files, inspect its history, change its code, run its checks, and prepare its pull requests. If the product intent exists only in another system, the agent has to remember to retrieve it, or someone has to paste a lossy copy into the conversation.

That makes the most important input optional.

We saw the mismatch in our own product. Agents were already authoring intents through the API. The human turn was increasingly review, not authorship. Meanwhile, the hosted-workspace-as-destination motion was not producing a durable habit. We were asking people to come to the product while their agents were already doing the work somewhere else.

The repository was not the final stop. It was the starting point.

intent.md is now the authority

An intent.md file is the portable record of what should be true: the objective, observable outcomes, hard constraints, edge cases, and verification checks for a change.

Over the past few weeks, we moved the workflow around that file:

• The repo-bound file wins. When a repository carries an intent.md, Pathmode's agent tools read that file first instead of guessing which workspace intent is current. The hosted record can enrich it with findings, handoff notes, and authorization. It does not silently replace the decision under discussion.
• The full loop runs where the agent works. Agents can create an intent, challenge it with a deterministic preflight, carry it into implementation, hand discoveries to the next session, and verify the result against the same outcomes.
• The format is open. IntentSpec has a normative specification, schema, conformance fixtures, and a normalization corpus that pins different parsers to the same reading, not merely the same pass-or-fail result.
• We built a bridge to OpenSpec, not a rival to it. Existing OpenSpec changes can run through the same readiness gate, and intent can move between the two formats with an explicit receipt for anything that cannot travel safely. The integration works with OpenSpec; it is not a partnership or a claim that one format should replace the other.
• Existing work can be adopted without being rewritten. A repository that already has an intent.md can connect it to a Pathmode workspace while preserving the body of the file. The adoption flow adds identity and a secure binding instead of asking the user to start over in a blank workspace.

This is more than an export feature. The file is the product's center of gravity.

If Pathmode disappeared tomorrow, an IntentSpec file should remain readable, implementable, and useful. Otherwise, it would be a proprietary funnel disguised as an open format.

What belongs outside the repository

Making the file authoritative does not mean putting every piece of product knowledge into git.

Some evidence should never be committed: customer interviews, identifiable support conversations, private research, and sensitive metrics. A repo-safe file can carry a summary and a stable reference. It should not carry the source material that contractors, forks, and every agent with repository access could read.

Human judgment also needs a door outside the repository. The person who knows whether a claim is true may be a product manager, researcher, support lead, or customer-facing teammate who will never open a pull request. They need a way to confirm, reject, or amend the claim without pretending to be a developer.

And no individual file can know that new evidence has undermined decisions spread across several repositories. That requires a view across the organization, not a smarter Markdown document.

Those are the three jobs of the hosted product:

1. Private evidence storage. The repo carries a safe reference. Pathmode holds the source.
2. Attributed human review. The file carries the decision. Pathmode can establish who stood behind the judgment and whether it still applies.
3. Cross-repository staleness. When evidence changes, Pathmode can identify the claims and repositories that need fresh judgment.

The boundary matters because it keeps both sides honest. The file should not become a thin client that stops working without Pathmode. Pathmode should not become another workspace trying to pull implementation away from the repository.

Today, the private evidence store and review surface exist. Attributed claim-level decisions and cross-repository staleness are the next proof points, not capabilities we should pretend are already complete.

Installs are not adoption

A repository can contain an intent.md that nobody reads. An MCP server can launch without performing a useful action. A session hook can notice that a file exists without changing a single decision.

None of those are adoption.

The behavior that matters is deliberate participation: an intent is created or materially updated, a person or agent deliberately runs a preflight, code is reviewed against the intent, a branch or pull request is linked to it, or an implementation is verified against its outcomes.

And it has to repeat.

Our north star is Weekly Repeated Intent Repos: repositories that perform a deliberate qualifying action this week and also participated during the preceding six weeks. It is weekly, not cumulative. When a repository stops using intent, it leaves the number.

Automatic reads and passive hooks never count. They can make the opportunity visible, but allowing them into the metric would let us manufacture adoption by having our own software read a file in the background.

The distinction is important. A repository where an agent reads intent.md, does the right work, and makes no Pathmode call is evidence that the repo-native thesis is working. A metric based on tool calls alone would call it failure.

A conviction with a falsifier

The repo-native path is not yet a validated growth channel.

We chose it because the alternative failed to produce habitual use, while one coherent signal kept appearing: agents were authoring intents, and the human job was becoming judgment rather than writing. The repository is also the natural distribution channel for an artifact consumed by coding agents.

That is enough for a conviction bet. It is not enough for certainty.

The bet becomes real only if repositories repeatedly use intent during actual work. If they do not, the channel is not pulling, however elegant the standard looks and however many packages get installed.

The failure condition is part of the strategy. Without it, "repo-native" could become standards theater: more schemas, fields, adapters, and conformance badges without a repeated behavior underneath them.

So new fields must earn their way in through real runs. Workflow changes must address observed friction or ship as time-boxed experiments. Hosted work must strengthen private evidence, attributed judgment, or staleness beyond one repository.

Everything else needs an unusually strong reason to exist.

The product we are building now

Pathmode is no longer trying to become the place where every part of product development happens.

The repository is where implementation happens. Product intent should be present there as living state: not trapped in a workspace, buried in a ticket, or reconstructed from a prompt after the original reasoning has disappeared.

Pathmode has a narrower job: keep the evidence safe, make human judgment trustworthy, and carry changes in that judgment back to the work.

The repo gets the decision.

Now we have to prove teams keep using it.