A Project Rule Projection Needs One Owner

A project can need rules in more than one tool format. That does not mean it needs more than one rule source.

This is the useful boundary behind APC rule projections: keep the project-owned instruction in .apc/rules/; let a compatible IDE or runtime create the format it needs to execute that instruction. The projection is useful. Editing both copies as if they were peers is where drift starts.

Source versus projection

Imagine a repository with a TypeScript API. The project wants every compatible agent working on routes to validate input at the boundary. APC can express that once:

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

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

That file says both what to do and where it applies. It belongs to the repository, can be reviewed with code, and travels when the repository moves.

A runtime may need that same rule under its own directory. For example, a compatible consumer can project .apc/rules/backend.mdc into a tool-specific rules folder. That derived file lets the runtime use its native loading mechanism. It should not become a second place where the team edits the policy.

Why two editable copies fail

At first, duplicate rule files look harmless. One is for an IDE. One is for another agent runtime. Then the API moves, an exception is added, or a review clarifies the wording. Someone updates only one copy.

Now the project has two answers to the same question. Both may be valid Markdown. Only one is current. Agents receive different instructions based on the tool that opened the repository, and reviewers have no reliable place to verify intent.

The problem is not that a runtime has its own configuration. Runtime-specific files can be necessary. The problem is unclear ownership. A projection is an adapter, not a competing contract.

Keep the split small

Use the broadest APC surface that matches the instruction:

• Put repository-wide rules in AGENTS.md.
• Put path-scoped or task-scoped rules in .apc/rules/.
• Put reusable procedures in .apc/skills/.
• Keep runtime-only setup, sessions, messages, and private state outside the portable contract.

This split makes an important maintenance question simple: where should a change be made? For shared project meaning, change APC first. Regenerate or update the runtime projection from that source. For a setting that only controls one local runtime, keep it local instead of pretending it is portable.

Where APX fits

APC is the portable context layer: repository-owned rules, agent definitions, skills, and other durable project meaning. It deliberately does not define every runtime's storage or execution behavior.

APX is the daily-use runtime and tooling layer. It bridges APC into compatible workflows, while keeping operational state such as sessions, messages, and caches outside .apc/. APX therefore benefits from a clear source of truth: it can consume project context without turning its local state into the project contract.

A review check

When a project adds a tool-specific rules file, ask one question: where is the canonical edit made?

If the answer is .apc/rules/, the team can review, version, and move shared guidance once. If the answer is “whichever copy someone remembers,” the repository has already started to fork its own context.

Portable context is not about banning adapters. It is about making sure adapters do not become authors.