APC Plans Keep Durable Work Out of the Chat

APC plans exist for one reason: some work should survive the session, but not the noise that produced it.

That is the clean split between APC and APX.
APC is the portable context layer, so it holds project-owned facts that should travel with the repo.
APX is the daily runtime and tooling layer, so it holds the messy work: sessions, transcripts, scratch notes, local state, and all the back-and-forth that gets you to a decision.

The mistake is simple: people either keep too little, or keep too much.
If you keep only the final code diff, you lose the reasoning that made the change safe.
If you dump raw chat into the repo, you import noise, private data, and half-finished ideas that nobody can trust later.
.apc/plans/ is the middle path.

A good APC plan is not a transcript and not a task board. It is a durable artifact that answers a specific question for future work.
The spec is explicit about what belongs there:

• implementation plans that are approved or still useful later
• migration plans
• release plans
• investigation summaries with next steps
• open decisions and constraints

That sounds small, but it is a strong rule.
It means a plan stays useful after the original session is gone.
It also means another tool, another machine, or another contributor can pick up the work without replaying the whole conversation.

A concrete example helps.
Imagine you are moving auth checks from a service into a gateway.
During the APX session, you may explore three designs, reject two, and test a couple of edge cases.
That process belongs in APX runtime state, because it is temporary and often noisy.
But the final shared decision is different:

---
title: "Auth migration"
status: active
owner: architect
updated: 2026-07-06
---

# Auth migration

## Goal
- Move token validation to the gateway.

## Constraints
- Preserve existing session cookies during migration.
- Keep the old path working until rollout is complete.

## Steps
- Add gateway validation middleware.
- Add compatibility tests.
- Remove duplicate service checks after rollout.

That file is worth keeping because it compresses a long conversation into something actionable.
It tells a future contributor what the project decided, what still matters, and what should happen next.
It does not ask them to trust a transcript.
It gives them the current contract.

This is the deeper point: APC plans are not for storing thought streams.
They are for storing decisions that have already earned their place in the repo.
That makes them reviewable, diffable, and portable.
A plan can move through code review like any other project artifact.
A raw session cannot.

APX still matters here, because APX is where the work happens day to day.
It is the runtime that can collect the session, keep the local audit trail, and help you recover the useful part.
But APX should not become a dumping ground for durable project intent.
The clean workflow is: work in APX, extract the stable facts, then write them into APC when they are safe and useful for the team.

That rule is easy to apply:

• If only the current session needs it, keep it in APX.
• If the whole project may need it later, put it in APC.
• If it is still fuzzy, keep it local until the decision settles.

Plans are the part of APC that makes projects remember how they move.
Not every conversation deserves a permanent record.
But every durable decision deserves a home.