max / makenotwork

Write down whether the version uploader can be described Counted across the tree: progress and the success/error surfaces need no new vocabulary and the host already draws them. The one missing shape is a queue of picked files with a field per row, which is a ruling for quasi-router and makeover-layout rather than a change here.

Author: Max Johnson <me@maxj.phd> · 2026-08-31 11:39 UTC

Signed with PGP, not checked

Commit: d6460e0624b44074175ec5b665af15d6d1a1942a

Parent: 598c703

2 files changed, +93 insertions, -1 deletion

M server/src/quasi/item_files.rs +83

			@@ -58,6 +58,89 @@
58	58		//! three buttons. That is the honest shape of what the screen offers, and it is
59	59		//! a affordance change Max may want to look at.
60	60		//!
	61	+	//! # Can the uploader move to the description layer?
	62	+	//!
	63	+	//! Three shapes, counted across the tree (MNW server, goingson,
	64	+	//! balanced_breakfast, audiofiles, quasi, makeover-layout). Two of the three
	65	+	//! need no new vocabulary at all, and the third is earned by the count but is a
	66	+	//! cross-repo ruling rather than this pass.
	67	+	//!
	68	+	//! **Progress with a filename, a percent, a rate and a cancel: no member
	69	+	//! wanted.** This is already ruled. [`Action::awaiting`] says the call waits
	70	+	//! and [`Action::by_host`] says who makes it, and
	71	+	//! [`super::upload_field`]'s header states the consequence: the mark says the
	72	+	//! call waits, and the renderer observes the rest. `static/upload.js`'s
	73	+	//! `progressPanel` is that observation, built in the host with no markup
	74	+	//! written down anywhere, and it already serves every described upload field.
	75	+	//! `Node::Meter` is not the shape and does not need widening. What the region
	76	+	//! below still holds is progress markup for the queue's run, which is markup
	77	+	//! only because the queue is.
	78	+	//!
	79	+	//! **A surface that persists until reset, with one thing to do about it: no
	80	+	//! member wanted.** `layout::Notice::Banner` is spelled "persistent, in flow,
	81	+	//! one per region, dismissed by fixing the cause", and [`Node::Notice`] grew an
	82	+	//! optional act (`bde35298`) precisely so that a sentence about a situation and
	83	+	//! the one thing to do about it are one thing. Success, error and Try Again are
	84	+	//! all sayable today. They are not said here because they are client state
	85	+	//! reached after an XHR rather than anything the server renders, and the
	86	+	//! described upload path already answers a failure with a toast.
	87	+	//!
	88	+	//! A queue of picked files, each with a status: 3 consumers, earned. This
	89	+	//! panel's `#version-upload-queue`, the bundle wizard's `#batch-file-rows`
	90	+	//! (`templates/wizards/steps/item/content.html`, driven by
	91	+	//! `static/wizard-item-content-bundle.js`), and the media library's
	92	+	//! `#media-upload-progress` (`static/tab-user-media.js`). Nothing outside MNW
	93	+	//! has the shape: goingson, balanced_breakfast and audiofiles have no picked-file
	94	+	//! queue between them.
	95	+	//!
	96	+	//! **The same queue with an editable field per row: 2 consumers, earned by the
	97	+	//! count and deferred anyway.** This panel carries one label per file; the
	98	+	//! bundle wizard carries a title and a type per file. Two is the bar, and two
	99	+	//! consumers that disagree about how many fields a row holds means the member
	100	+	//! has to be a slot holding several fields.
	101	+	//!
	102	+	//! There are two near misses and neither is it. [`Repeat`] is a repeating
	103	+	//! field: a slot is one answer to one question, and its own docs name the
	104	+	//! wire naming that would have to grow (`name[0].label` beside `name[0]`).
	105	+	//! [`Repeating`] (`f7abbc08`, ruled by Max the same day, over widening
	106	+	//! `Repeat`) is the repeating group, which is the phrase this queue wants,
	107	+	//! and it still does not carry the queue. Its own text is what says so, on
	108	+	//! both of the points that separate a picked-file queue from a group of
	109	+	//! answers:
	110	+	//!
	111	+	//! - Its `add` is a whole [`Act`] "because adding a slot here is a route: the
	112	+	//! group's state is the app's". The queue's slots are not added by anything
	113	+	//! that can be a route. They arrive from a file picker, live in the browser,
	114	+	//! and are gone once the run finishes, which is the case `Repeating` names
	115	+	//! as the other one when it contrasts a repeating field "whose slots live
	116	+	//! in the renderer's own view until they are submitted".
	117	+	//! - Its wire section carries nothing, because "these regions each carry their
	118	+	//! own fields with their own writes, so every slot is already addressed by
	119	+	//! the routes inside it". A queue slot has no route of its own to be
	120	+	//! addressed by. Its label is read back out of the row at submit time
	121	+	//! (`item-upload.js` reads `.version-label-input[data-idx]`), which is
	122	+	//! exactly the `name[0].label` naming `Repeat` says it does not have.
	123	+	//!
	124	+	//! And the queue trips `Repeating`'s stated reopening condition head on: it
	125	+	//! deliberately carries no per-slot error, "**that is the reopening
	126	+	//! condition**", while a queue row's whole reason to exist is a per-row status
	127	+	//! that includes failure (`updateQueueStatus`, four states, one of them
	128	+	//! `error`). So the member is still missing, and the shape the evidence points
	129	+	//! at is the wider `Repeat` that ruling set aside rather than a second region
	130	+	//! member beside `Repeating`.
	131	+	//!
	132	+	//! That is a vocabulary ruling to reopen and a forward fix across two sibling
	133	+	//! repos, not a panel conversion, and reopening a call Max made hours earlier
	134	+	//! is his to make rather than this pass's. The counting is done and written
	135	+	//! down here so the next pass does not repeat it; the region stays until the
	136	+	//! member exists.
	137	+	//!
	138	+	//! [`Node::Notice`]: quasi_router::Node::Notice
	139	+	//! [`Repeat`]: quasi_router::screen::Repeat
	140	+	//! [`Repeating`]: quasi_router::Repeating
	141	+	//! [`Act`]: quasi_router::screen::Act
	142	+	//! [`Action::awaiting`]: quasi_router::Action::awaiting
	143	+	//! [`Action::by_host`]: quasi_router::Action::by_host
61	144		//! [`Action::get`]: quasi_router::Action::get
62	145		//! [`Action::replacing_enclosing`]: quasi_router::Action::replacing_enclosing
63	146

M server/templates/partials/item_version_upload.html +10 -1

			@@ -5,7 +5,16 @@
5	5		of it `static/item-upload.js`.
6	6
7	7		The wrapper keeps its own id and `data-item-id`: the script reads them, and
8		-	a described region carries no host dataset. -#}
	8	+	a described region carries no host dataset.
	9	+
	10	+	Whether this region can be described was counted on 2026-08-30 and the
	11	+	answer is written down in `crate::quasi::item_files`, "Can the uploader move
	12	+	to the description layer?". Short version: the progress surface and the
	13	+	success/error surfaces need no new vocabulary and are the host's to draw
	14	+	already, and the one shape that is missing is a queue of picked files with a
	15	+	field per row. `quasi_router::Repeating` is the near miss and its own docs
	16	+	rule it out; the answer is a ruling in `quasi-router` and `makeover-layout`
	17	+	rather than a change here. -#}
9	18		<div class="version-upload" id="version-upload" data-item-id="{{ item.id }}">
10	19
11	20		<!-- New Version Form -->