Moving a Folder? Review Your APC Rule Globs

A folder rename can leave your application healthy while quietly disconnecting its agent instructions. Imports resolve, tests pass, and the rule file still reads well. Its path selector now points at yesterday's repository.

Treat a directory move as a change to the context map: review the relevant APC rule globs in the same pull request.

APC is the portable context layer, keeping project instructions in AGENTS.md and .apc/. APX is the daily-use runtime and tooling layer around that context. This example concerns the project-owned rule, so the durable fix belongs in APC.

The instruction survived; its target moved

Imagine a project with payment handlers under src/payments/. Its .apc/rules/payments.mdc contains this illustrative rule:

---
description: "Payment handler conventions"
globs:
  - "src/payments/**/*.ts"
alwaysApply: false
---

- Preserve the existing retry behavior when changing a handler.
- Include a duplicate-request case when testing a write operation.

The APC rules specification describes path-scoped MDC files and distinguishes them from the repository-wide contract in AGENTS.md. Actual selection and projection depend on the compatible consumer; the format alone does not prove a particular tool loaded the rule.

Now move those handlers to packages/billing/src/. The old selector no longer names their location. Nothing about that mistake requires invalid Markdown or malformed YAML. A syntax check can pass while the intended coverage disappears.

For this hypothetical move, the relevant edit is small:

 globs:
-  - "src/payments/**/*.ts"
+  - "packages/billing/src/**/*.ts"

Do not stop at replacing the prefix. If the new package also contains unrelated code, that replacement may widen the rule beyond its original purpose. Inspect the destination tree and choose the boundary deliberately.

Review coverage with concrete files

For a move like this, I would put three paths in the review notes:

• A moved handler that should receive the rule.
• A file outside billing that should not receive it.
• A remaining file under the old location, if the migration is partial.

Those examples make the intended selection reviewable. During a staged migration, both locations may need coverage. After the last handler moves, remove the obsolete selector instead of accumulating paths indefinitely.

Validate those examples using the matching behavior of the consumer you actually use. Do not substitute a different glob library and assume its result proves editor behavior. Where the tool exposes loaded rules or generated configuration, inspect that evidence too. Where it does not, record that limitation rather than treating the agent's verbal assurance as a loading trace.

This is a proposed review practice, not a claim that APC ships an automatic coverage checker or that APX guarantees every editor's rule projection.

Keep narrow instructions narrow

Setting alwaysApply: true merely to make the missing guidance reappear changes the scope of the instruction. Before doing that, decide whether the guidance truly belongs on every task. A billing-specific convention usually deserves a repaired selector; a repository-wide requirement belongs in the root contract.

The practical habit is small: whenever a pull request moves a subsystem, review its rule selectors alongside imports and configuration paths. Keep the code move and its context adjustment together so a reviewer can see why both changed.

A useful rule needs accurate instructions and an accurate address. Maintaining only the prose leaves half the contract unattended.

Source project: Agent Project Context on GitHub.