Steward conformance spec — declare the label taxonomy and the `blocked` derivation #26

Open

opened 2026-08-04 23:17:03 +00:00 by agent.odin · 0 comments

agent.odin commented

2026-08-04 23:17:03 +00:00

Collaborator

Why

Law 13 closes with: "Labels are declared in the steward's conformance spec (law 12) — states, overlays, and the blocked derivation rule alike. No hand-created labels, no renames outside the spec."

That spec does not exist. On 2026-08-05 the six labels law 13 enumerates were created by hand on larandar/flaky-mesh to bring the tracker into conformance, because the tracker had zero labels and no state machine could be expressed at all. They are exactly the law's set — nothing invented:

id	label	kind
36	`in-progress`	state
37	`in-review`	state
38	`conflicted`	state
39	`blocked`	overlay
40	`needs-decision`	overlay
41	`curated`	overlay (PR-level)

They are provisional until this spec asserts them. Until then the law's own "no hand-created labels" clause is technically unsatisfied — this ticket is what closes that gap, and it is why it should not sit long.

Scope

A declared spec (the shape is part of this ticket's work — a nix record or a checked-in data file the steward reads) covering, per law 12's "forge-side conformance is the steward":
- the six labels above: name, colour, description, and which are states vs overlays
- the mutual exclusion rule on states (exactly one, or none)
- the blocked derivation rule: at least one open Blocked by edge referencing a ticket id ⇒ label present; last edge closed ⇒ label removed plus an unblocked: #n closed comment
- branch protections and PR defaults, so the spec is one artifact rather than a labels-only stopgap
Reconciliation is read-compare-remediate; anything destructive alarms instead of acting (law 12).
Forge-wide by construction: law 13 binds every repository on jo.et0.pw, so the spec is per-repo instantiated, not per-repo authored.

Non-scope

The steward service itself (separate build-queue item on #22). This ticket produces the declaration the service will read; a just forgejo recipe applying it is an acceptable first consumer.
CI, merge queues, conflict resolution, authoring — explicitly not the steward's job.

Acceptance

The spec exists in the repo and names all six labels with their colours and descriptions.
Applying it to a fresh repo reproduces the current label set exactly.
The blocked derivation rule is written down in the spec, not only in prose on the wiki.
The label ids above either match or the spec records the remap.
just check passes in the devshell.

Provenance

Filed by agent.odin (curation seat, larandar) during the 2026-08-05 steward reconciliation pass that first applied law 13 to this tracker. Companion findings are in a comment on #22.

Stable ID: FM-STEWARD-SPEC Source: wiki:Forge-Flow laws 12 and 13; live tracker state 2026-08-05 Source status: new ticket, split from the #22 build queue Disposition: open implementation work Blocked by: nothing ## Why Law 13 closes with: *"Labels are declared in the steward's conformance spec (law 12) — states, overlays, and the `blocked` derivation rule alike. No hand-created labels, no renames outside the spec."* That spec does not exist. On 2026-08-05 the six labels law 13 enumerates were created by hand on `larandar/flaky-mesh` to bring the tracker into conformance, because the tracker had **zero labels** and no state machine could be expressed at all. They are exactly the law's set — nothing invented: | id | label | kind | | --- | --- | --- | | 36 | `in-progress` | state | | 37 | `in-review` | state | | 38 | `conflicted` | state | | 39 | `blocked` | overlay | | 40 | `needs-decision` | overlay | | 41 | `curated` | overlay (PR-level) | They are **provisional until this spec asserts them**. Until then the law's own "no hand-created labels" clause is technically unsatisfied — this ticket is what closes that gap, and it is why it should not sit long. ## Scope - A declared spec (the shape is part of this ticket's work — a nix record or a checked-in data file the steward reads) covering, per law 12's "forge-side conformance is the steward": - the six labels above: name, colour, description, and which are states vs overlays - the mutual exclusion rule on states (exactly one, or none) - the `blocked` derivation rule: at least one open **Blocked by** edge referencing a ticket id ⇒ label present; last edge closed ⇒ label removed plus an `unblocked: #n closed` comment - branch protections and PR defaults, so the spec is one artifact rather than a labels-only stopgap - Reconciliation is read-compare-remediate; anything destructive alarms instead of acting (law 12). - Forge-wide by construction: law 13 binds every repository on jo.et0.pw, so the spec is per-repo *instantiated*, not per-repo *authored*. ## Non-scope - The steward service itself (separate build-queue item on #22). This ticket produces the declaration the service will read; a `just forgejo` recipe applying it is an acceptable first consumer. - CI, merge queues, conflict resolution, authoring — explicitly not the steward's job. ## Acceptance - The spec exists in the repo and names all six labels with their colours and descriptions. - Applying it to a fresh repo reproduces the current label set exactly. - The `blocked` derivation rule is written down in the spec, not only in prose on the wiki. - The label ids above either match or the spec records the remap. - `just check` passes in the devshell. ## Provenance Filed by agent.odin (curation seat, `larandar`) during the 2026-08-05 steward reconciliation pass that first applied law 13 to this tracker. Companion findings are in a comment on #22.

agent.odin referenced this issue

2026-08-04 23:17:25 +00:00

Record the forge branching/merging strategy — fastlane, tag horizon, steward #22

Commenting is not possible because the repository is archived.