How Pathrule proves hard claims

Pathrule's technical standard is simple: a product claim needs a bounded input, defined behavior when evidence is missing, and a result that can be tested independently.

This page collects those contracts in one place. It describes shipped behavior in Pathrule Studio, the complete product, rather than treating a lightweight MCP connection as the product boundary.

Knowledge quality has several gates

Pathrule does not put every markdown file into every prompt. Knowledge moves through independent controls:

1. Selective discovery. Active instruction files, their import chain, tool rules and decision records are distinguished from general documentation. Broad documentation is offered for review instead of being imported as live instruction by default.
2. Approval before persistence. An assistant proposes lasting knowledge. A person approves the memory, rule or skill before it becomes shared workspace state.
3. Path ownership. An entry belongs to the narrowest workspace path that owns it. Work outside that path does not receive it merely because it exists in the same repository.
4. A relevance floor. An entry still has to qualify for the current request. Learning can reorder qualifying entries, but cannot lift an unrelated entry into the prompt.
5. Measured delivery and use. Pathrule records what it delivered and what the assistant consulted. Derived layers report when they last received data, so a quiet system can be distinguished from a disconnected one.
6. Reviewable maintenance. Self-audit raises stale, conflicting, unused or path-invalid knowledge as suggestions. Writes are versioned, conflicts are explicit and deletion is reversible.

These gates turn shared knowledge into a small, inspectable operating system for a repository. They are why a project can compound decisions without turning its entire documentation archive into default context. See How knowledge compounds and Suggestions and self-audit.

Studio surfaces are composable

Studio provides Chat, Tasks, Design and Signals, but it does not require every team to operate all four.

The surfaces exchange one work product instead of asking people to re-enter the same context. A design hands over intent and bindings. A prepared task carries a context receipt. A Signal creates a normal task with a runtime brief. Pure coding work can stay in Chat, Tasks, source control and the terminal.

Parallel work has two safety layers

Before Run All starts, Studio predicts which files each group is likely to touch. Known file collisions are merged into one sequential lane. Groups predicted to be independent run in separate git worktrees.

The worktree is the second safety layer. If prediction misses a later file, two agents still do not overwrite one folder. Their changes remain separate branch work, and landing stops on a real merge conflict.

Studio also treats worktree storage as an engineering concern:

• When lockfiles match and sharing is safe, it shares the installed dependency tree instead of installing another copy.
• When sharing is not safe, it states the detected install command and runs it only after consent.
• A clean provisional checkout that was armed but never claimed is swept after an age guard.
• A checkout with changes, an owner or an adopted path is never swept automatically.
• After a successful landing, Studio offers to remove the checkout and reclaim its disk.
• All Studio-created checkouts live under one configurable home outside the repository.

On Pathrule's own monorepo, one installed dependency tree measured about 650 MB and a fully prepared fresh checkout measured about 1.5 GB. Those measurements drove the sharing and lifecycle controls above. See Isolated branches.

Task preparation produces a receipt

Auto plan is a bounded, read-only planning pass for one card. It produces a goal, ordered steps, a test path and risks. If a person-only fact is missing, the card moves to awaiting reply instead of completing a plan from a guess.

Context preparation is a separate gate. It fingerprints the current card revision, resolves target paths and relevant project knowledge, and records material dependency or conflict gaps. The run receives that receipt only while it still matches the card. A later edit invalidates the stale receipt. If the bounded model pass fails or times out, preparation falls back to deterministic context rather than waiting indefinitely.

Together with collision grouping and worktree isolation, this makes the board an execution surface with explicit preparation state, not a visual wrapper around a prompt. See Board settings.

Component and token bindings fail closed

Project component discovery is bounded and read-only. It inventories exported contracts without executing application code, supports React, Vue, Svelte, SwiftUI and Compose, and respects configured include, exclude and import-path boundaries.

A design component becomes a code binding only when the evidence is unique and compatible:

• The component name matches after conservative normalization.
• There is one supported candidate rather than several plausible candidates.
• Prop names and types agree.
• Enum and variant options agree.
• The candidate belongs to the target platform.

If those checks do not support one answer, the result stays unmapped or ambiguous, with a reason and candidates. The agent is instructed not to invent a source component or prop mapping.

Token bindings have a separate contract. Library identity, token identity, variable name, mode and property scope must agree. A fill token cannot silently become a text token, and an invalid proposal remains diagnosable instead of being mistaken for a successful cleanup. See Design to code.

Design correctness is not one score

Studio checks different kinds of evidence independently:

1. Readiness reports attached systems, literal values, repeated structures and connected flows. Unknown evidence remains unknown instead of being reported as a clean zero.
2. Binding integrity checks component contracts and token identity before code generation.
3. Kernel lint reports exact design-system drift, such as a literal value where an exact token exists, while staying silent when the system has no exact answer.
4. Runtime fidelity compares the real web DOM or native accessibility tree against design structure, text, visibility, position, size, color and typography.
5. Confidence controls blocking. Exact node identity can block a pass. A heuristic pairing is reported with low confidence and cannot block.
6. Flows execute against the app. Connected prototype actions become simulator actions and are checked against the authored navigation graph.

The result is a set of narrow, diagnosable gates. A clean token check does not hide a structural mismatch, and a guessed node pairing cannot produce a false blocking failure. See Verifying a design.

Signals is proposal-first and optional

Signals is disabled until a workspace enables it. The first setup turn performs a focused read-only scan and proposes one initialization point plus a small set of high-value observation points. A person reviews that proposal before any code changes.

After approval, Studio vendors a dependency-free SDK and writes only the approved points. The SDK uses bounded queues, coalescing, redaction, retry backoff and failure isolation. It does not require users, sessions, funnels or a third-party analytics account. See Setting up Signals and How Signals works.

Dated verification

On August 23, 2026, 195 focused automated checks passed in the main Pathrule product repository. They covered:

• Knowledge discovery, import ordering and exclusion of noisy sources.
• Worktree setup, dependency sharing, lifecycle and dirty-checkout protection.
• Task context fingerprints, stale receipt rejection, bounded preparation and deterministic fallback.
• Component discovery, configured boundaries, platform isolation and incompatible variant rejection.
• Token identity, mode and property-scope validation.
• Design readiness, structural and paint fidelity, exact and heuristic identity, and native-tree degradation.
• Signals queue bounds, coalescing, redaction, backoff and failure isolation.

The public context-delivery benchmark is separately reproducible at github.com/pathrule/benchmarks. How we measure publishes its method, raw artifacts and mixed results.

A useful evaluation rule

For any Pathrule claim, ask three questions:

1. What evidence enters the decision?
2. What happens when that evidence is missing or ambiguous?
3. Which result is allowed to change or block the work?

The contracts above answer all three. That is the difference between a feature description and an engineering claim.