design: specify action dispatch identity and uncertain outcomes

[Maya-Kid]

A synchronous run-then-record cannot distinguish an unsent action from a remote side effect whose response was lost. ADR 0050 records the proposed execution identity, revision-bound preview, original-flow dispatch grant and uncertain outcome, including why retries and recovery takeover are unsafe without another contract.

This revision is documentation-only. The Python protocol model, tests and requirements file were archived outside the repository and removed from the PR tree. Both decision indexes now contain 0050, and 0034 has a dated note at its synchronous-run boundary. No production schema, sender, route or recovery behavior is introduced.

Validation at 8f3d189d46478f437df57b4a823556dfc493dcbf against dev 69560db5969fae8def8c4e84b7572d841e1dca57: diff scope, two index entries, relative links, contextual revision note, proposed status and absence of executable scaffolding all passed. No fresh Rust/sender test claim is made for this documentation-only revision. The 19 model tests and mutation findings in the record are explicitly historical, tied to the original model revision.

Request identity and revision binding, no automatic retry, no redirects and no recovery takeover remain proposals for maintainer review. HTTP observation remains distinct from business completion; this does not promise external exactly-once execution.

Refs #530

[WaylandYang]

The content here is decision material — it states a policy and asks maintainers to approve it — and the thinking in it is good. My objection is only about where it lives.

docs/decisions/README.md states the purpose of that directory plainly: code records what was built and git records when it changed; neither records why, and that directory does. Putting the reasoning in scripts/prototypes/**/README.md and leaving a five-line pointer in the accepted record splits it. A reader who opens the record in six months finds a stub aimed at a directory whose name says "prototype" — with no number, no row in either index table, no status line for an implementing PR to update, and none of the revision discipline the conventions require. The "Decision requested" section is exactly the thing that is supposed to be numbered and indexed.

Please give this its own numbered record in docs/decisions/, and turn the addition to the accepted record into a dated revision note that names it, per Revisions stay in place.

#832 in this same batch is the pattern to copy: it moved its reasoning into docs/decisions/0048-provenance-references-stay-inside-the-knowledge-base.md, added the row to both index tables, opened an issue for the open design question, and left the migration carrying only what SQL has to say.

One thing that is not my call and that I have flagged for the maintainer: whether the executable prototype itself belongs in the repository. scripts/bench/ is tracked, so there is precedent for committed harnesses, but these add a Python harness and a requirements.txt, and that is a policy question rather than a review point.

[WaylandYang]

Decision on the committed prototype directories, so all three of these can move at once: the conclusions belong in a numbered record; the harness stays out of the repository.

The test we are applying is not "prototype versus production". It is: after the decision is made, will anyone run this again?

• If yes, it is a bench and it belongs next to what it measures. scripts/bench/govern.mjs is tracked for exactly that reason — 0025 cites it, and when the governance prompt changes someone reruns it against the labelled pair set. Its value recurs.
• If no, the finding goes in the record and the scaffolding does not enter git. That was the call on the HotpotQA harness earlier: the durable artifact was the number, not the rig.

There is a second reason, and it is the stronger one: an executable specification that is not the implementation is a second source of truth. This is the thing the codebase avoids everywhere else. 0032 refuses to store an expression as a string and evaluate it at run time; the rule model is structured precisely so that what the page shows is generated from what runs and cannot drift from it. A policy module that encodes the rules beside the validator rather than inside it is that same drift, with the added property that nothing will ever fail when the two disagree.

So: please lift the reasoning and the decisions requested into a numbered record under docs/decisions/, add the row to both index tables, and turn the paragraph added to the accepted record into a dated revision note naming it, per Revisions stay in place. #832 is the pattern — it moved its reasoning into docs/decisions/0048-provenance-references-stay-inside-the-knowledge-base.md, indexed it, and opened an issue for the question it wanted maintainers to settle.

None of this is a judgement on the work itself. The analysis is good and the experiments clearly did their job; the argument is only about what survives them.

Applied to this PR: protocol.py and test_protocol.py are 422 lines of Python sketching a dispatch protocol for a Rust system, and the file's own docstring says it is not Utopia's action implementation. When 0034 is built it will be built in Rust, and this becomes a design document that happens to execute. requirements.txt would also open a Python dependency line in a Rust and TypeScript repository, which is a bigger commitment than this experiment needs.

The identity and fault-boundary model is the valuable part, and it reads as decision material — put it in the record.

[WaylandYang]

This is still marked as a draft, so I have not merged it — a draft is your signal that it is not finished, and flipping that is your call rather than mine.

From my side the rework answers everything I raised: the reasoning is now a numbered record with rows in both index tables, the accepted record carries a dated revision note pointing at it, and the committed harness is gone. CI is green on all four checks and it merges cleanly onto dev.

Mark it ready for review when you consider it done and I will merge it.