Path-Scoped Rules Belong in APC

A repository should not need different hidden rule copies for different tools.

That is why path-scoped rules belong in APC.

APC is the portable context layer. It keeps repository-owned meaning in AGENTS.md and .apc/. APX is the daily-use runtime and tooling layer. It helps current agents and runtimes work with that portable context while still keeping sessions, messages, and other runtime state outside the repo.

The split matters most when one rule should apply only to one part of the codebase.

One repo, different rule zones

Most projects do not have one flat instruction surface.

Frontend code may need accessibility checks and bundle-size discipline. Backend code may need input validation at the route boundary. Support content may need a specific tone and escalation path. If all of that lives only in one giant root prompt, agents either ignore the details or carry too much irrelevant guidance into every task.

APC gives a cleaner shape:

• AGENTS.md for repository-wide rules
• .apc/rules/ for reusable or path-scoped rules

The APC rules spec is explicit about this. AGENTS.md is the broad root contract. .apc/rules/ is where rules can become smaller and more targeted.

A recommended file can look like this:

---
description: "Backend API rules"
globs:
  - "src/api/**/*.ts"
alwaysApply: false
---

- Validate request input at the route boundary.
- Keep database writes inside service functions.

That is a better boundary than copying the same instructions into Cursor rules, Claude-specific files, and a runtime-local note that no one reviews.

Why APC should own these rules

Path-scoped rules are still project meaning.

They describe how this repository wants work done in these paths. That is exactly the kind of information that should survive a fresh clone, code review, and a runtime change. If the rules live only in one editor's private directory, they stop being part of the project contract and start being workstation trivia.

APC fixes that by keeping the source in .apc/rules/.

The folder structure docs make the intent clear: path-scoped .mdc rules are project-owned, safe to commit, and distinct from runtime state. Sessions, conversations, messages, caches, and private memory do not belong there. APX keeps those under ~/.apx/ instead.

That separation keeps two different concerns from bleeding together:

• APC stores durable guidance worth reviewing.
• APX stores local operational history worth keeping out of git.

Why this also helps APX

APX works best when the repository already has a clean contract.

The APC reference docs describe APX as the runtime bridge that makes .apc/ usable today. It handles the daemon, CLI, runtimes, engines, and local storage. It should not become a second source of truth for project rules.

If path-scoped guidance already lives in APC, APX can stay thin. It can help compatible runtimes use the repo context without owning a second project-specific rules database.

That is also future-proof. The APC rules docs explicitly allow compatible consumers to project .apc/rules/*.mdc into tool-specific rule systems when needed. The important part is not the projection target. The important part is the source stays in the repo.

Practical example

Suppose a monorepo has these needs:

• AGENTS.md: run tests before merge, never commit secrets, keep migrations reversible
• .apc/rules/frontend.mdc: preserve keyboard navigation and avoid text-only icon buttons
• .apc/rules/backend.mdc: validate input at the boundary and keep writes inside services

Now the project can move across tools without rewriting its own discipline each time.

APC keeps the rule map portable. APX keeps the runtime local. That is the right division of labor.

Bottom line

Path-scoped rules belong in APC because they are part of the repository contract, not part of one runtime's private memory.

Keep broad rules in AGENTS.md. Keep narrower, reusable, path-aware rules in .apc/rules/. Let APX handle execution, sessions, and local tooling around that contract instead of duplicating it.