docs(plan): Step 3 tells an implementer to build a class that belongs to 2c-D

[cryptskii]

The correction

Step 3 says "Then build TA_B (0x0011, …)".

The CCB object registry lists 0x0011 TraderAcceptance as blocked — 2c-D, and says plainly:

Ownership of 0x0011 itself is 2c-D's — 2c-B disclaims it, and 2c-C4 records that TA_B verification moves with its field table.

2c-C4 gives the reason in its charter note: an amendment cannot specify the verification of an object whose fields another amendment defines.

So an implementer following Step 3 literally would set out to build a class that is not yet defined, and would find that out only after writing the surrounding machinery.

The part that makes 5c-2 startable anyway

Recorded alongside it, because on its own the above reads as "5c-2 is blocked", and it is not. 2c-C4 rules the interim state exactly:

After C4 and before 2c-D: accepted-successor verification may succeed and validated economic admission may succeed — and a market fold remains PartialPendingRealization. It MUST NOT be promoted to realized from correspondence alone.

So Step 2 and Step 3 may lift the market emission refusal and carry a trade as far as bound-but-unrealized. Realization, fence release, receipt publication and TA_B all wait for 2c-D.

That distinction is the difference between 5c-2 being blocked and 5c-2 being startable, and it was not written down anywhere. The constraint on doing so is that nothing downstream may read a bound fold as realized, which is Ruling R1 and is already enforced by the withhold theorems.

Form

Added to the existing second status block rather than opening a third, and the plan body is still not rewritten.

Verification

Markdown only. Neither make lint nor ci/production_safety_checks.sh reads markdown, so neither gate's result can change; CI runs both regardless. Every quotation was read from origin/main.