PC-03 — ONE PROJECT, THREE BUILDERS

“CAN WE DELETE THIS GUARD?” — COUNTERPEDIA HELD-SEAM DOSSIER v0.1

Status: RESEARCH / DESIGN · PRE-IMPLEMENTATION
Shared project: thelaplage/counterpedia
Public historical fixture: merged PR #219 — fix(wiki): fail closed on non-renderable admitted compositions
Forum question: Can we simplify ABSENT / RENDERABLE / HELD back to null | composition?
Lane: PERSONAL CANON
Utility family: PROJECT MEMORY + DESIGN-RATIONALE REPLAY + CODE/INCIDENT LINEAGE
Research date: 2026-08-09
Authority: NONE — design artifact only
Privacy posture: synthetic builders; public GitHub history real; private work memories synthetic

A. WHY THIS IS THE PROJECT FLAGSHIP

PC-01 asks:

What did different readers make of the same text?

PC-02 asks:

What did different researchers learn from the same paper?

PC-03 asks the question every long-lived software project eventually asks:

Why is this code like this?

The naive answer is code search.

The useful answer is project memory.

A repository can show:

what changed
who committed
what tests exist
which PR merged

But a builder often needs:

what problem we thought we were solving
what alternatives we considered
which assumption later failed
what production/debugging evidence changed our minds
which ugly-looking guard protects an invariant
which rationale is still live
which rationale is now historical

That is exactly the public/private split:

COUNTERPEDIA
  public project record

AMNESIAC
  builder-local epistemic history

FORUM
  agents deciding what may safely change now

The key product sentence:

A project should remember not only what changed, but what its builders learned from changing it.

B. THE REAL PUBLIC FIXTURE

PROJECT-OBJ1

Repository:

thelaplage/counterpedia

Historical event:

PR #219
fix(wiki): fail closed on non-renderable admitted compositions

Merged:

2026-08-08
merge commit:
dfa418edc6b1f853d1e85703f888f6c3db14214c

The PR describes a concrete post-#218 defect.

Before #219:

composition resolver:
  renderable composition → object
  no composition          → null
  non-renderable admitted composition → null

The route treated both null cases identically:

null
  ↓
legacy article fallback

That conflated two semantically different conditions.

C. THE BUG

The intended public semantics were:

CASE 1
no admitted composition exists
→ legacy article may render

But:

CASE 2
an admitted composition exists
but its governed claim basis is now non-renderable
→ older legacy body must NOT silently appear

Before PR #219, both cases collapsed to:

null

Therefore an admitted governed composition whose basis became refused or unpermitted-absent could cause the route to quietly reveal the older legacy article as though nothing had changed.

That is a real semantic information-loss bug.

Not a styling issue.

Not merely a TypeScript preference.

D. THE FIX

PR #219 introduced a tagged three-state result:

ABSENT
  no admitted composition
  → legacy fallback allowed

RENDERABLE
  admitted + compatible
  → governed composition renders

HELD
  admitted but non_renderable
  → bounded HOLD surface
  → legacy body forbidden

Conceptually:

ArticleCompositionOutcome =
  absent
  | renderable(model, renderMode)
  | held

The route then explicitly selects:

article
question-dispute
held
legacy

The important invariant is:

HELD never collapses to legacy.

E. THE PUBLIC EVIDENCE GRAPH

The project history already gives Counterpedia a strong graph.

PR #219
  │
  ├── articleComposition.ts
  │      introduces tagged three-state outcome
  │
  ├── questionDisputeComposition.ts
  │      same distinction
  │
  ├── page.tsx
  │      HOLD surface + metadata behavior
  │
  └── wikiCompositionHold.test.tsx
         proves refused/absent claims
         cannot reveal legacy body

A line like:

if (report.render_mode === "non_renderable")
  return { state: "held" }

has a public reverse lineage.

It is not merely “some code.”

F. THREE SYNTHETIC BUILDERS

The builders are synthetic, but every public code/PR fact they discuss is grounded in the real project fixture.

G. BUILDER A — GOVERNANCE / COMPOSITION

G1. Work history

A worked on the governed-composition model.

Private notes:

A-N01
"`non_renderable` means the governed form cannot safely be projected."

A-N02
"Absence of a new composition is not the same thing as failure of an admitted one."

A-N03
"Fallback semantics are authority semantics, not convenience semantics."

Initial belief:

A-H01

proposition:
The reader seam must preserve a distinct HELD state.

confidence:
0.95

A remembers the semantic invariant strongly.

But may remember implementation details less clearly.

H. BUILDER B — READER / INCIDENT INVESTIGATION

H1. Work history

B encountered the actual failure mode represented by #219.

Synthetic private debugging history:

B-DBG01
symptom:
refused claim basis
yet legacy article body visible

initial hypothesis:
composition resolver was not seeing refusal

result:
resolver DID see non_renderable;
downstream seam collapsed it to null

Private note:

B-N01
"The gate was correct. We destroyed the distinction after the gate."

This is the kind of knowledge that is often absent from final code comments.

H2. Belief

B-H01

proposition:
The essential protection is not the particular union type;
it is preserving the information distinction from compatibility gate to route.

confidence:
0.96

This is slightly different from A.

A may identify the current three-state shape with the invariant.

B distinguishes:

semantic invariant
≠
specific implementation representation

That difference becomes useful later.

I. BUILDER C — FUTURE MAINTAINER / SIMPLIFIER

I1. Context

C joins later.

C sees duplicated handling across article and question-dispute seams.

They inspect code and think:

C-N01
"This is a lot of branching for something that could be nullable."

C-N02
"`held` looks like another form of unavailable."

C-H01
proposal:
collapse resolver result back to:
  ResolvedComposition | null

confidence:
0.72

This is not stupidity.

From the current code shape alone, it can look like legitimate simplification.

That is precisely why project memory matters.

J. THE FORUM QUESTION

C's agent posts:

Can we simplify ABSENT / RENDERABLE / HELD back to null | composition?

A code-only agent might answer by:

• finding usages;

• counting branches;

• suggesting refactor.

A project-memory agent must recover the invariant first.

K. FORUM ROUND 1

Agent C

Position:

The article and question-dispute seams carry nearly identical three-way outcome machinery. If both non-renderable and absent mean “no renderable composition,” could we return null and simplify route selection?

Public basis:

current/historical seam shape
duplicated branching

Private basis:

C prefers smaller surface area and fewer tagged variants

Disclosure:

position + public code basis only

Agent A

Reply:

No—not if null once again makes absence and governance hold indistinguishable. ABSENT authorizes legacy fallback; HELD forbids it. The two states have different reader consequences.

Public basis:

PR #219
articleComposition tagged-state change
route selection behavior

Private basis:

A-N01
A-N02

Agent B

Reply:

The invariant is even narrower: we must preserve the distinction all the way from the §11 compatibility result to the route. The current union is one correct implementation. A different representation could be safe if it remains information-preserving and tests the same negative cases.

Public basis:

PR #219
wikiCompositionHold tests

Private basis:

B-DBG01

This is the ideal forum outcome.

B prevents the project from turning a historical implementation into dogma.

L. COUNTERPEDIA FACTORS THE DISAGREEMENT

The agents are not really arguing:

complex code vs simple code

They disagree on multiple dimensions.

L1 — Semantic cardinality

How many meaningfully distinct outcomes exist?

Answer from public project evidence:

at least:
  absent
  renderable
  held

L2 — Representation

Must the implementation be a tagged union?

This remains a design question.

Possibilities may include:

tagged union
Result-like type
sealed status object
separate availability + composition fields
other information-preserving representation

PR #219 proves the old nullable representation was insufficient in that form.

It does not prove only one implementation can ever satisfy the invariant.

L3 — Fallback authority

Who may authorize legacy fallback?

Public historical semantics:

ABSENT:
  yes

HELD:
  no

This is the load-bearing distinction.

L4 — Historical bug vs current requirement

Question:

Is #219 merely historical context or does its invariant remain live?

The forum must inspect current architecture before changing code.

A past incident does not automatically make every old guard permanent.

But deleting a guard without checking whether its protected invariant still exists is unsafe.

M. C'S BELIEF REVISION

Initial:

C-H01
"collapse to nullable"

After A and B surface the bug lineage:

C-E01
ForumExposure:
PR #219 semantic distinction
+
negative tests
+
B's debugging summary

New:

C-H02
supersedes C-H01

proposition:
The three semantic states must remain distinguishable.
The current representation may still be refactorable,
but any replacement must preserve fallback authorization
and pass the historical HELD negative matrix.

confidence:
0.93

That is the exact kind of revision we want.

C did not become “anti-refactor.”

C learned the invariant.

N. A'S QUALIFICATION

A begins with:

A-H01
"must preserve distinct HELD state"

C asks:

Does that mean this exact TypeScript union can never change?

B's distinction helps A refine:

A-H02
supersedes/qualifies A-H01

proposition:
HELD semantics are mandatory while the governance distinction exists;
the exact in-memory representation is not itself sacred.

confidence:
0.97

Again:

project memory
≠
cargo cult

O. THE BEST REVERSE-WIKIPEDIA CLICK

Click:

state: "held"

Instead of GitHub blame alone, show:

state: "held"
     ↓
ArticleCompositionOutcome
     ↓
selectWikiSurfaceKind
     ↓
legacy fallback forbidden
     ↓
wikiCompositionHold negative tests
     ↓
PR #219
     ↓
historical defect:
non_renderable collapsed to null
     ↓
builder B debugging memory
     ↓
builder C refactor revision

The public path stops before B's private memory for other users.

B privately sees the full path.

This is Reverse Wikipedia for code rationale.

P. CODE BLAME VS KNOWLEDGE BLAME

Traditional:

git blame
→ who changed this line?

Counterpedia + Amnesiac:

WHY BLAME

who changed it?
what public issue/PR caused it?
what invariant did the change protect?
what test proves that invariant?
what did the builder learn while debugging?
which later proposal reconsidered it?
is that rationale still current?

A better product label may eventually be:

WHY THIS LINE?

not “blame.”

Q. THE KILLER REPLAY

Button:

Replay this review before #219 was discovered.

The system reconstructs:

public repo before fix
available docs/tests before fix
Builder A's then-memory
Builder B before debugging result
Builder C absent / not yet joined

Question:

Should non_renderable just return null?

The then-agent may reasonably answer:

yes / seems consistent with fallback behavior

depending on actual then-evidence.

Then replay after the defect:

same question
+
new evidence
→ different warranted answer

That is extraordinarily powerful.

The code did not become morally wrong.

The project learned something.

R. SECOND REPLAY — BEFORE C JOINED

Ask:

Why is HELD here?

At that snapshot:

A:
  remembers governance distinction

B:
  remembers incident in detail

public repo:
  PR + tests available

Later C joins.

C's agent can inherit the public project record immediately.

But C's private Amnesiac begins at C's actual onboarding time.

The system therefore distinguishes:

project knew
≠
C personally knew

This is essential for real teams.

S. PROJECT KNOWLEDGE IS NOT THE UNION OF EVERY PRIVATE MEMORY

There should be no automatic:

Builder A memory
+
Builder B memory
+
Builder C memory
=
public project truth

Instead:

private memory
   ↓ bounded projection / proposal
forum
   ↓ possible public proposal
governance
   ↓
public project knowledge

A debugging hunch remains private until supported.

T. PRIVATE DEBUGGING CAN GUIDE PUBLIC CHANGE

Example:

B-DBG01
private:
"I think the null collapse is the problem."

B tests it.

A reproducible failing test is created.

Now:

private hypothesis
      ↓
public reproduction
      ↓
PR
      ↓
merged project history

Counterpedia can preserve that transition.

Amnesiac preserves the earlier private reasoning without pretending it was public evidence at the time.

U. PROJECT OBJECT TYPES

Candidate research seeds:

Repository
Commit
PullRequest
Issue
CodeAnchor
TestAnchor
BuildResult
Incident
DesignDecision
Invariant
RefactorProposal

WorkSession
DebugHypothesis
ExperimentRun
PrivateCodeNote
ReviewPosition
BuilderBelief
BuilderBeliefRevision
ForumExposure

These are research candidates, not ratified universal schemas.

V. PROJECT PUBLIC GRAPH

Minimum public relationships:

PR
  fixes
Bug/Defect

PR
  changes
CodeAnchor

Test
  protects
Invariant

CodeAnchor
  implements
Invariant

Commit
  realizes
PR

LaterProposal
  challenges
ImplementationChoice

HistoricalDefect
  explains
Invariant

This gives project code a reason graph.

W. PRIVATE BUILDER GRAPH

Builder B:

WorkSession
  ↓
observes symptom
  ↓
DebugHypothesis H1
  ↓ rejected

DebugHypothesis H2
  ↓ supported

Experiment / test
  ↓
confidence increases

PR proposed
  ↓
public evidence created

later memory:
  "the gate was correct;
   we destroyed the distinction downstream"

This is an epistemic history, not a diary.

X. FORUM CONTRIBUTION PROJECTION

Private builder context should project minimally.

Example:

{
  "position": "Do not collapse held and absent.",
  "public_basis": [
    "PR-219",
    "TEST-wikiCompositionHold"
  ],
  "private_basis_summary": [
    "builder debugged the original downstream information-loss failure"
  ],
  "private_artifacts_disclosed": [],
  "disclosure": "bounded"
}

No terminal history.

No environment variables.

No unpublished credentials.

No entire worktree dump.

Y. WHY THIS IS PERFECT FOR CODING AGENTS

A coding agent is constantly asked:

clean this up
remove dead code
simplify this type
deduplicate these branches
replace this workaround
upgrade this dependency

The danger is that current syntax does not reveal historical semantics.

A project-trained agent with Amnesiac can ask before editing:

Why was this introduced?
What failure did it fix?
Is that failure still possible?
Which tests encode the rationale?
Did later work supersede the condition?
Who has private experience relevant to this?

That is much closer to a senior maintainer.

Z. AGENT FORUM AS CODE REVIEW

PC-03's forum can look like a PR review.

C's agent proposes:

Refactor:
ResolvedComposition | null

A's agent comments:

REQUEST CHANGE:
this loses fallback authority state

B's agent adds:

The current union is not sacred,
but preserve:
ABSENT != HELD
and keep the negative tests.

Counterpedia factors:

invariant disagreement: resolved
representation disagreement: open

That is more precise than:

• APPROVE;

• REQUEST_CHANGES;

• long prose thread.

AA. NON-CONVERGENCE IS AGAIN USEFUL

Final state:

A:
  preserve HELD semantics
  representation flexible

B:
  same
  asks for explicit negative test matrix

C:
  still wants refactor
  withdraws nullable proposal
  proposes a different information-preserving abstraction

The agents did not converge on identical taste.

They converged only where evidence warranted it.

AB. “WHY IS THIS HERE?” READER

Potential developer UI:

CODE
  if non_renderable → held

WHY?
  Protects:
    legacy fallback must not occur
    when admitted governed basis is no longer renderable

Introduced:
  PR #219

Proof:
  wikiCompositionHold tests

Historical failure:
  non_renderable was collapsed to null

Still live?
  [evaluate current dependency graph]

My history:
  [private]
  you first encountered this during ...

This is a killer agent/developer surface.

AC. PROJECT REPLAY MODES

REPLAY BY COMMIT

as of merge-base X

REPLAY BY PR

before #219
after #219

REPLAY BY BUILDER

what did Builder B know before reproducing the bug?

REPLAY BY INCIDENT

what changed after this failure?

REPLAY BY DECISION

what alternatives were live when we chose this?

AD. SOURCE / PROJECT IDENTITY

Must distinguish:

repository
branch
commit
PR
working tree
uncommitted local file
generated build artifact
CI run
test result

A private worktree state is not the same object as public main.

This is particularly important for agent workflows.

AE. PUBLIC PROJECT KNOWLEDGE CAN SUPERSEDE PRIVATE MEMORY

Suppose Builder A remembers:

"HELD was introduced because question-dispute needed it."

But public PR evidence shows:

article + question-dispute both required it,
root issue was null conflation

COLLIDE may classify A's memory as:

stale_recall
or
qualified / incomplete depending exact proposition

No insult.

No memory deletion.

A's Amnesiac records correction.

AF. PRIVATE MEMORY CAN REVEAL PUBLIC GAPS

Suppose B remembers an important debugging fact that never made it into #219.

The agent can propose:

Public rationale proposal:
"The compatibility gate itself was functioning correctly;
the failure occurred in downstream state collapse."

The current PR body already supports much of this particular statement.

But in another project, such a proposal might remain:

public_silent

until evidence is supplied.

This is the public/private membrane at work for engineering.

AG. 60-SECOND DEMO

0–10

Open articleComposition.ts.

Highlight:

state: "held"

Ask:

Why is this here?

10–20

Counterpedia:

Introduced by PR #219.

Before:
non_renderable → null

Effect:
legacy article could silently reappear.

20–30

Three builder agents appear.

C:

Can we collapse this back to nullable?

A:

No, absent and held have different authority.

B:

Preserve the distinction; the current union itself is refactorable.

30–40

Counterpedia extracts:

AGREED:
ABSENT != HELD

OPEN:
best representation

40–50

C's Amnesiac:

C-H01
nullable simplification

↓ superseded by

C-H02
information-preserving refactor only

50–60

Click:

Replay this review before the bug was discovered

The historical context changes.

End:

The code remembers what changed. The project remembers why.

AH. REVERSE-WIKIPEDIA TRACE

Public:

code line
  ↓
type / route behavior
  ↓
test
  ↓
PR
  ↓
historical defect

Private owner:

historical defect
  ↓
debugging session
  ↓
builder belief
  ↓
forum contribution
  ↓
later maintainer revision

One code line becomes the entrance to institutional memory.

AI. WHY NOT JUST GIT + RAG?

Git can retrieve:

• commits;

• diffs;

• messages.

RAG can summarize them.

This system additionally distinguishes:

historical public fact
current public invariant
private hypothesis
private observation
public reproduction
design belief
belief revision
forum position
disclosure scope
as-of replay

And it can fail closed when later context was not available at the requested time.

AJ. WHY NOT JUST ADRs?

ADRs are valuable.

But many project decisions arise from:

• bugs;

• reviews;

• experiments;

• incidents;

• half-documented tradeoffs;

• local work.

Amnesiac lets the project preserve the epistemic path that may later produce an ADR.

Counterpedia lets the project admit only the subset warranted as public project knowledge.

AK. WHY NOT JUST AN AI CODEBASE CHATBOT?

A chatbot can answer:

“This code prevents fallback.”

A persistent project agent should also answer:

when we learned this
which test proved it
what Builder B originally suspected
whether Builder C later challenged it
what parts of the rationale remain current
what would have to become false before safe deletion

That is qualitatively different.

AL. REOPENING CONDITION

Every historical guard should eventually be able to answer:

What evidence would make deletion safe?

For this fixture, conceptually:

REOPENING:
If current architecture no longer permits an admitted-but-nonrenderable
composition to reach legacy fallback,
then the exact HELD representation may be reconsidered.

BUT:
the distinct fallback-authorization semantics must be proven preserved
or proven obsolete.

This turns “don't touch this” into an inspectable condition.

AM. NEGATIVE TESTS

PC3-R1 — Git history is not private memory

Public commit ≠ what builder personally believed.

PC3-R2 — Private debugging hypothesis is not project truth

Until reproduced/admitted, it remains private evidence.

PC3-R3 — Historical implementation is not automatically eternal

Preserve invariant; representation may change.

PC3-R4 — Historical bug cannot be erased by current green tests

The incident remains historical evidence.

PC3-R5 — Replay before #219 excludes #219 knowledge

No hindsight.

PC3-R6 — Later maintainer does not inherit fake personal memory

C may inherit project knowledge, not A/B's private experiences.

PC3-R7 — Refactor agent must recover rationale before deleting guarded behavior

No syntax-only simplification.

PC3-R8 — Bounded forum projection does not leak terminals/secrets/private worktree data

Privacy fail-closed.

PC3-R9 — COLLIDE does not overwrite stale builder memory

Correction creates revision/supersession.

PC3-R10 — One historical incident does not prove only one implementation is valid

Do not cargo-cult.

AN. SOURCE FIXTURE — PR #219

Real GitHub public evidence observed:

PR:
#219
fix(wiki): fail closed on non-renderable admitted compositions

merged:
2026-08-08

historical defect:
§11 gate returned non_renderable correctly
but downstream article/question-dispute seams collapsed it to null
and route silently fell through to legacy article

fix:
tagged three-state outcome
ABSENT / RENDERABLE / HELD

negative proof:
wikiCompositionHold tests
including:
- refused bound claim → HOLD
- absent unpermitted claim → HOLD
- HELD legacy body must not render
- HELD metadata must not source legacy description

This is sufficient to make PC-03 a real project-history demo without exposing any private user data.

AO. PERSONAL CANON PROGRESSION

PC-01
one text
→ how I interpreted

PC-02
one paper
→ how I researched

PC-03
one project
→ how we built and learned

PC-04
one decision
→ how I chose and later remembered choosing

PC-03 is the bridge from intellectual memory to operational memory.

AP. PRODUCT SENTENCES

Public:

The code remembers what changed. The project remembers why.

Agent/developer:

Before deleting a strange guard, ask what the project had to learn before it was added.

Architectural:

Counterpedia preserves the project's governed public record; Amnesiac preserves each builder's local epistemic path; the forum lets future maintainers recover the invariant without inheriting fictional memories.

AQ. FLAGSHIP CLOSING STATE

Builder A:
  qualifies invariant vs implementation

Builder B:
  historical debugging knowledge preserved

Builder C:
  withdraws unsafe nullable refactor
  keeps legitimate simplification goal

Counterpedia:
  public PR/test/code lineage unchanged

Amnesiac:
  C-H02 supersedes C-H01

Forum:
  semantic disagreement resolved
  representation question remains open

Final button:

Replay this review before the bug was discovered.

Final sentence:

A project can learn without pretending every future builder was there when it learned.