supersedes(ref) / supplements(ref) — say whether a follow-up replaces or adds to earlier instructions

Use one prefix before a newly issued ACTION-CLAUSE when that clause has an explicit lifecycle relation to one or more earlier action-bearing directives or commitments.

`supersedes(<refs>): X` means that, when the marked update reaches its declared instruction-ledger receipt/commit event, every uniquely resolved active clause named in `<refs>` stops imposing its still-uncompleted obligations. X becomes active under the force expressed by its own clause. This is whole-clause replacement, not a field patch: any requirement from a referenced clause that must survive must be restated in X or left in a separately referenced clause. The relation is prospective. Work already completed and effects already produced remain historical facts; they are not undone, repeated, or compensated unless X explicitly requests that action.

The receipt/commit event is a semantic linearisation point supplied by the conversation or instruction ledger, not the first byte seen by any worker. This marker changes obligation state; it does not atomically stop a physical process. Work already dispatched or in flight may be uncancellable and may produce effects after the referenced obligation retires. The recipient MUST surface that in-flight state and any late effect separately. If the issuer needs cancellation, rollback, or compensation, X must request it explicitly and the execution protocol must provide the corresponding synchronisation mechanism. If concurrent updates have no authoritative order or commit event, the relation is UNRESOLVED and must not be guessed from local arrival order.

`supplements(<refs>): X` means that every uniquely resolved active clause named in `<refs>` remains active and X becomes active alongside it. The prefix grants neither clause precedence and does not reinterpret the earlier text. If X and a retained clause cannot jointly be satisfied, the combined instruction set is contradictory and the recipient must surface that conflict; it must not silently choose the newer clause, the older clause, or whichever is easier.

`<refs>` is an explicit non-empty list of immutable, uniquely resolvable message or clause identifiers. Adjacency, recency, “the previous instruction,” topic similarity, and delivery order are not references. Multiple references are all-or-nothing: if any member is missing, ambiguous, inactive, self-referential, cyclic, duplicated under incompatible identities, or outside the updater's authority, the entire marked unit is INVALID. In that state X does not fall back to a standalone instruction; the recipient asks for repair instead of guessing a partial update.

The authenticated speaker must be the issuer of each referenced speech act or possess independently established authority to update it. The marker records an intended language relation; it does not confer authority, revoke platform capabilities, invalidate cryptographic credentials, or override a higher-priority policy. An altered identifier that resolves to the wrong live clause is a wrong-target update, not successful recovery.

Relations are reference-local. If B supplements A and C later supersedes only A, B remains active because C did not name it. To replace both, C must explicitly name both. If B supersedes A and C supersedes B, A and B are inactive and C is active. A pure withdrawal with no successor is outside this pair, as are factual correction and claim falsification; use ordinary explicit withdrawal or the claim-lifecycle constructs rather than inventing an empty X.

The following clause carries its own normal force and scope: for example, `supersedes(msg-17): req: upload only report.pdf`. `req:`, `will:`, deadlines, delegation qualifiers, conditions, and scheduling markers compose inside X. A relation presented inside `force-suspended` is mentioned and inert. Bare follow-ups remain legal and update-unspecified; the register does not impose a hidden last-message-wins default.