ONE PROJECT, THREE BUILDERS

STATUS: RESEARCH / DESIGN ONLY.

Real public fixture

Repository: thelaplage/counterpedia

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

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

Public evidence to bind

At minimum:

• PR #219 metadata/body;

• changed lib/counterpedia/articleComposition.ts;

• changed app/(site)/wiki/[slug]/page.tsx;

• tests/wikiCompositionHold.test.tsx;

• exact merge commit.

Do not infer current implementation state from historical PR bytes without checking current main if implementation begins.

Synthetic builders

A — governance/composition

• remembers absence vs held as distinct authority states.

B — reader/debugging

• private synthetic debugging memory: gate returned non_renderable correctly; downstream state collapse lost the distinction.

C — later maintainer

• begins wanting nullable simplification.

Required forum outcome

Factor:

1. semantic cardinality;

2. representation choice;

3. fallback authorization;

4. historical bug vs current requirement.

Do not frame: complexity vs simplicity

as the only disagreement.

Required revisions

C:

• C-H01 = nullable simplification.

• after evidence, C-H02 = preserve semantic distinction; representation remains refactorable.

A:

• qualify “keep HELD” into: semantic HELD distinction mandatory while invariant exists; exact TypeScript representation not sacred.

Required reverse trace

state:"held" → route selection → negative test → PR #219 → historical defect

Private owner extension:

historical defect → B debugging memory → forum → C belief revision

Required replay

Replay this review before #219 was discovered

Exclude:

• PR #219;

• post-fix tests;

• B's later debugging conclusion;

• C's later revision.

Then replay after #219.

Demonstrate different warranted answers.

Privacy negatives

• no terminal logs by default;

• no env vars/secrets;

• no entire private worktree projection;

• a private debugging summary can influence forum position without raw-artifact disclosure.

Project-memory negatives

• Git commit is not builder belief.

• builder belief is not public project truth.

• historical implementation is not automatically eternal.

• one incident does not prove only one representation is valid.

• future builder inherits public rationale, not fictional personal memories.

Acceptance

PC-03 succeeds if:

code line has public rationale lineage
three builders bring different warranted histories
unsafe simplification is revised
legitimate refactoring remains open
private work history stays private
public project history stays source-grounded
replay removes hindsight

End:

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