Decide a publish prototype

The journey gives the checker one reading and one answer: the request's header, the proposed change against the last published values, the checks run over the candidates, the rule that decides the request, and the decisions already taken.

The open question is how that reading and the answer that follows it belong on one screen. The checker must see what the request would change before the controls that change it, and the screen must say when the request needs more than one pair of eyes and that the checker is one of them.

Switch with the bottom bar, or with ?variant=a, ?variant=b or ?variant=c. The default is a.

The variants disagree about where the queue belongs, not about the request. All three render the same header, delta, checks, decisions and answer, in that order.

Switch with the bottom bar, or with ?state=waiting, ?state=held, ?state=decided or ?state=multi. The default is waiting.

The state decides the kind's count as well as the request: in multi the header reads approvals_required, and two distinct people must approve.

The bottom bar switches the variant and the state, and every change is written to the query string through URLSearchParams, so any pair can be linked. The decision buttons are live: press Approve, Refuse or Hold and the note records the answer by m.oduya with a comment. Clear the comment first and the press is refused with "A comment is required", because a refusal always needs one and this kind also asks for one on approval. Every control is prototype chrome, and the banner states the variant and the state in hand.

Everything on the page is mock data: the curves, the tenors, the candidate and last published values, the checks, the queue, the people, the kind, its deciding group, its permission and its seven-day life are hard-coded literals. There is no server, no session and no build step. A decision writes a sentence into the note and the page is unchanged on reload. The "no marker" in the delta and the "unknown" beside each check state what the server cannot yet answer.

doc/prototypes/market_data/decide-a-publish/. The directory holds one file, index.html, with its CSS and its JavaScript inline: no framework, no prototype.css, no prototype.js, and no build step. The site build copies the directory through ores-deploy-web-app as it stands and adds nothing to it. No build file names the prototype, and nothing in the directory is compiled, generated or rewritten.

The group accepted the argument and recorded it as the row this note answers to: the checker decides from the delta and the checks, with a comment, and the kind may ask for more than one pair of eyes. What the group took is the reading before the answer, a comment bound to the decision, and a request whose count is read from its kind.

The three variants and the four states stayed on the page as the record of the question, so a later screen can borrow a panel from any of them. The group kept the request's own shape, not a particular arrangement of the queue: the header, the delta, the checks, the decisions so far, then the answer.

The baseline. Nothing marks a curve published, so there is no delta to read and the panel shows the candidate values against "no marker". Whether the system holds the last published set, or the screen builds the difference, is open.

The checks. No operation runs the three checks over a candidate set and returns a result, so each reads unknown: not checked, not passed.

The deciding group. The model names a decide permission and not a group, so "Market data approvers" is a candidate the page shows beside the permission code rather than a name it trusts.

The record around the decision. Whether the reason is kept, whether expiry is enforced, whether a hold takes a reason from a list, and how the maker is told what was decided are open; Approval requests argues the general shape.