feat(standard): §11.3.6 — Steelbore Hanzo Steel — v2.05

CHANGELOG.md

@@ -20,6 +20,8 @@ Entries are newest-first. Dates are UTC, ISO 8601 (§14). Versioning policy: bum
 for upstream skill changes, registry updates (§2.1, §15.1), factual corrections
 to normative content, and brand/identity changes.
 
+- **v2.05 (2026-09-15):** **§11.3.6 registers a tenth palette — Steelbore Hanzo Steel, the family's first pure-black canvas.** The palette's colours are drawn from the poster art for *Kill Bill Vol. 1*, and it is anchored on **Sumi Black** and **Hanzo Gold**. **The name is the standard's own, deliberately.** §11.3.2 set a precedent for film-derived palette names, but a palette name is published prose in a CC-BY-SA document, and a film title is a trademark this project has no licence to use as a product label. Colours are not protectable and the inspiration is stated plainly in the section; the identifier is not borrowed. **The substantive decision is the red, and §11.3.6 explains it in the text rather than leaving a reader to compare hexes and wonder.** The source art's Venetian red measures **4.03:1** on Sumi Black and **3.39:1** on Scabbard Slate — under the 4.5:1 text floor on the canvas, and far enough under it on the surface that error prose would not have been readable at normal size. It ships deepened, as **Crimson Edge**, for exactly the reason §11.3.4 deepens NavyWhite's status hues: a conforming alternate is not a §11.5 fidelity palette, so nothing obliges it to reproduce a source value that misses the floor. The alternative was considered and rejected — shipping the verbatim red would have bought fidelity to a poster with an `error` token no application could set in body text, and would have made this the only conforming palette whose error role is restricted on all three of its own backgrounds. **The result is a palette with no restricted pairings at all**: every foreground token clears 4.5:1 against canvas, surface, and surface-alt, the weakest being `error` on `surface` at 4.85:1, and `steelbore-hanzosteel-high-contrast` lifts `error` alone to Ember Lift (9.58:1) because every other token already clears 7:1. **A second thing the section states rather than assumes:** three golds carry three distinct roles — `accent`, `warning`, `structure` — separated by luminance rather than hue, which is legible but is precisely the case §18.2.1 exists for, so the text records that every coloured status in this palette carries its `[WARN]` or `[ERROR]` tag. **Counts move throughout**, and they are the bulk of the diff: ten palettes and nineteen themes, eight conforming, six alternates in §11.3, and the §11.6.1 registered set grows from thirteen to **fifteen** — so the arithmetic in that subsection now reads *three of the fifteen were already required, so this section adds twelve*. The §16 checklist's §11.6 bullet follows. **Unchanged:** every existing palette, every existing ratio, the §11.1 eleven-role contract, §11.4's one-palette rule and its inverted tie-break, §11.5's two non-adoptable fidelity palettes, and §11.6's two-stage resolution order. `steelbore-navywhite` remains the only light canvas, so §11.6.2's light/dark pairing is untouched and Hanzo Steel pairs to it like every other dark member. Also corrected in passing: `@settitle` had read `2.03` since v2.03 while `@set VERSION` moved to `2.04`, so the PDF and HTML title pages have been one version behind the document they title. No project conforming at v2.04 becomes non-conformant at v2.05. This is the Standard side; the skill encoding syncs at the same version and date.
+
 - **v2.04 (2026-09-14):** **§15.4 and §15.5 added — what produced an artifact becomes a machine-readable local record.** §15 has carried two attribution axes since the standard's early versions: §15.2 records who maintains an artifact, §15.3 records whose work it stands on. Neither records *what produced it*. When a model drafts a PRD, an implementation plan, or a task list — or codes a project outright — which model, at what reasoning effort, served by which provider, driven by which harness is knowledge that lives in the maintainer's memory of the session and decays within days. **§15.4 obligates a record; §15.5 specifies its form.** The form is an append-only JSON Lines log, **`.agent-log.jsonl`** at the repository root, one line per completed task. A draft of this section existed at v1.50 and was never landed; it required a *committed* table (an `AUTHORS.md`, or a closing `Authoring Model` section) written once per artifact. **That mechanism is not what ships.** The log is per-task rather than per-artifact, structured rather than prose, and **git-ignored rather than committed** — and the section says plainly what that costs: the record never reaches a clone and makes **no published claim** about the artifact. It serves the working copy that produced the work, answering what the maintainer can ask months later about which configuration did what, how often tests passed first try, and what the work cost. An artifact that must tell *consumers* who stands behind it still uses §15.2, unchanged. The `Co-Authored-By:` trailer is compared and kept: §15.4 faults it for being unstructured, for being lost to squash-merges and the history rewrites §6.3 permits, and for naming a product without the reasoning effort, provider, harness, or any measurement — **not** for recording activity, which is precisely what the log does too. The two are independent and both may be used. **Schema:** six required fields (`task_id`, `timestamp`, `model`, `provider`, `harness`, `files_touched`) and six optional (`reasoning_effort`, `subagent_role`, `test_pass_first_try`, `iterations`, `tokens_in`, `tokens_out`); unknown fields are permitted. `provider` and `harness` are required because §15.4's rationale turns on the combination of the three being what makes a result reproducible — the model alone does not. `reasoning_effort` is its own field rather than being folded into the model identifier, JSON having real fields where a table cell did not. Timestamps are RFC 3339 UTC + `Z`, which §14.3 already required of all `jsonl` output. **The harness writes the log, not the model**, and the section explains why: token counts are not observable by a model during its own session, and a model told to report them supplies plausible invented numbers — so **a field the harness cannot determine is omitted, never estimated**, an absent field being a truthful statement that the value is unknown. A reference `SessionEnd` hook is given that reads the real transcript. §15.5 also states the `.gitignore` entry is required and that the log SHOULD be excluded from agent file context, and notes explicitly that none of this conflicts with §5.7's requirement that `AGENTS.md` and `CLAUDE.md` be *tracked* — those carry project knowledge a fresh clone needs, the log is local measurement a fresh clone has no use for. **Unchanged:** §15.1–§15.3 in full, the §15.2 attribution block, the existing trailer convention, and §4.3 licensing metadata — a §15.4 record is a production fact, not legal authorship, and MUST NOT appear in an `SPDX-FileCopyrightText` tag, a `# Maintainer:` line, or `--version` output. The §15 chapter menu gains two entries and §16 gains one checklist bullet, marked N/A for hand-written artifacts. No project conforming at v2.03 becomes non-conformant at v2.04. This is the Standard side; the skill encoding syncs at the same version and date.
 
 - **v2.03 (2026-09-14):** **§11 stops restating colour values — `steelbore.toml` becomes the single source, and §11.4's tie-break clause is inverted.** §11 has always named `steelbore.toml` as "the canonical machine-readable source" and told implementors that **values are read, never retyped** — and then printed all 157 of them itself, across eleven `@multitable` blocks spanning §11.0 through §11.5. The instruction and the document disagreed, and §11.4 resolved that disagreement in the document's favour: *"Where this document and that file disagree, this document governs and the file is corrected."* That clause was not wrong so much as it was the cost of having two copies — something had to break the tie, and the specification is the natural winner. **The fix is to stop having two copies.** Every hex and every RGB triple is removed from §11; each table now names the token and the role it plays, with the value obtained from the file. Where dropping a value column would have destroyed meaning the column was converted rather than deleted — §11.1.1's "Variant hex" is now "Variant token" and reads `Plasma Orange Lift` where it read `#FF8A3D`, and unlifted rows say `(unchanged)` instead of repeating their base. The seven per-palette "Color" headers became "Token" for the same reason. **§11.4's tie-break clause is inverted, and that is the normative heart of this release**: the file now governs every value and §11 governs the contract around it — which roles exist, which are mandatory, what the contrast guarantee covers, which palettes are adoptable. The two can no longer disagree about a colour because only one of them states one, and changing a colour is now a single edit rather than an edit plus a search for every restatement. **The cost is stated in §11.4 rather than left for a reader to discover: §11 can no longer be implemented from this document alone.** A reader of the PDF, HTML, or Info output gets role names, contracts, and palette membership, but must obtain `steelbore.toml` for any actual colour. That is a real reduction in the document's self-sufficiency, accepted deliberately in exchange for values having exactly one definition. **Unchanged:** every role name, every contrast guarantee, the §11.0.2 matrix (contrast *ratios* stay — a measured ratio and a WCAG threshold are textually identical, so removing one would have removed the other), the palette family and its membership, §11.5's non-adoptable fidelity palettes, and §11.6's resolution order. No project conforming at v2.02 becomes non-conformant at v2.03. This is the Standard side; the skill encoding syncs at the same version and date.

The_Steelbore_Standard.md

@@ -29,7 +29,7 @@ repository](https://github.com/Spacecraft-Software/Standard), newest
 entry first. It is kept out of this document so the standard reads as
 the rules *in force* rather than the record of how they got there.
 
-This document is **version 2.04**, updated 2026-09-14 (§14: UTC, ISO
+This document is **version 2.05**, updated 2026-09-15 (§14: UTC, ISO
 8601). The skill encoding of the standard keeps a parallel history in
 `spacecraft-steelbore-standard/references/CHANGELOG.md` in the
 [Construct
@@ -941,6 +941,7 @@ the alternates.
 | `steelbore-matrixgreen` | Steelbore MatrixGreen | `Circuit Navy` | Dark | Alternate (§11.3) |
 | `steelbore-navywhite` | Steelbore NavyWhite | `Pearl Silver` | **Light** | Alternate (§11.3) — the family’s only light canvas |
 | `tokyonight` | Tokyo Night | `Night` | Dark | Alternate (§11.3) |
+| `steelbore-hanzosteel` | Steelbore Hanzo Steel | `Sumi Black` | Dark | Alternate (§11.3) |
 
 **Polarity** is the canvas’s light/dark class, and it is normative
 content: §11.6.2 pairs a dark palette with a light one so an application
@@ -1157,9 +1158,9 @@ Red Oxide is 1.13:1 and Radium Green on Liquid Coolant is 1.01:1.
 
 ## §11.3 — Alternate Palettes
 
-Five alternate palettes are registered. Each declares its own canvas,
-its own surfaces, and a full set of §11.1 role tokens verified against
-all three of its backgrounds. **A project adopts exactly one palette**
+Six alternate palettes are registered. Each declares its own canvas, its
+own surfaces, and a full set of §11.1 role tokens verified against all
+three of its backgrounds. **A project adopts exactly one palette**
 (§11.4); tokens are never mixed across palettes.
 
 Ratios below are *vs that palette’s canvas*. The complete
@@ -1328,6 +1329,56 @@ drawn in `structure` per §11.0.1.
 the canvas: `accent` to Tokyo Blue Lift (8.44:1) and `error` to Sakura
 Lift (8.22:1). The other six carry over verbatim.
 
+### §11.3.6 — Steelbore Hanzo Steel
+
+Anchored on **Sumi Black** and **Hanzo Gold**. The palette’s colors are
+drawn from the poster art for *Kill Bill Vol. 1*; the name is the
+standard’s own, so that a published specification does not carry a film
+title it has no licence to. Sumi Black is the family’s **only pure-black
+canvas** — every other member, light or dark, tints its ground.
+
+| Role token    | Token          | vs canvas |
+|---------------|----------------|-----------|
+| `background`  | Sumi Black     | (canvas)  |
+| `surface`     | Scabbard Slate | 1.19:1    |
+| `surface-alt` | Ink Well       | 1.06:1    |
+| `foreground`  | Bone White     | 18.49:1   |
+| `accent`      | Hanzo Gold     | 14.77:1   |
+| `structure`   | Tempered Gold  | 11.79:1   |
+| `success`     | Mint Signal    | 13.02:1   |
+| `error`       | Crimson Edge   | 5.77:1    |
+| `warning`     | Gold Leaf      | 14.01:1   |
+| `focus`       | Hanzo Gold     | 14.77:1   |
+| `border`      | Tempered Gold  | 11.79:1   |
+
+Every foreground token clears 4.5:1 on all three backgrounds — no
+restricted pairings. The weakest pairing in the palette is `error` on
+`surface` at 4.85:1.
+
+**Crimson Edge is a deepened hue, and the section says so rather than
+leaving a reader to wonder why the source red is not the shipped one.**
+The poster’s red measures 4.03:1 on Sumi Black and 3.39:1 on Scabbard
+Slate — below the 4.5:1 text floor on the canvas, and on the surface
+below it by enough that error prose would have been unreadable at normal
+size. It is deepened here for the same reason §11.3.4 deepens
+NavyWhite’s status hues: this is a conforming alternate, not a §11.5
+fidelity palette, so nothing obliges it to reproduce a source value that
+does not reach the floor. A palette that shipped the verbatim red would
+have bought fidelity to a film poster with a `error` token no
+application could set in body text.
+
+Three golds carry three distinct roles — `accent`, `warning`, and
+`structure` — and they are separated by luminance rather than by hue.
+That is legible, but it is not sufficient on its own: §18.2.1 already
+forbids color as the sole carrier of meaning, and a warning
+distinguished from an accent only by being one gold rather than another
+is exactly the case that rule exists for. Every colored status in this
+palette carries its `[WARN]` or `[ERROR]` tag.
+
+`steelbore-hanzosteel-high-contrast` lifts `error` alone, to Ember Lift
+(9.58:1); every other token already clears 7:1 on the canvas and carries
+over verbatim.
+
 ## §11.4 — Palette Selection
 
 - **Modern is the default.** An artifact that declares nothing uses
@@ -1419,6 +1470,7 @@ of each `[palettes.<slug>]` table.
 | `steelbore-matrixgreen`      | `matrixgreen-color-palette`      |
 | `steelbore-navywhite`        | `navywhite-color-palette`        |
 | `tokyonight`                 | `tokyonight-color-palette`       |
+| `steelbore-hanzosteel`       | `hanzosteel-color-palette`       |
 | `solarized-dark`             | `solarizeddark-color-palette`    |
 | `solarized-light`            | `solarizedlight-color-palette`   |
 
@@ -1543,18 +1595,18 @@ A project **authors** against one palette and **registers** several.
 These are different obligations, and §11.4’s one-palette rule governs
 only the first.
 
-The **registered set** is the thirteen themes that bind the §11.1
+The **registered set** is the fifteen themes that bind the §11.1
 eleven-role contract:
 
 | Obligation | Themes | Why |
 |----|----|----|
-| **MUST register** | The six conforming palettes — `steelbore`, `steelbore-blue`, `steelbore-blackpinkpanther`, `steelbore-matrixgreen`, `steelbore-navywhite`, `tokyonight` — each with its `-high-contrast` sibling, plus `steelbore-mono`. Thirteen themes | Every one binds the same eleven role tokens, so a theme layer that reads `steelbore.toml` registers them in a loop. A declaration can then always be answered |
+| **MUST register** | The seven conforming palettes — `steelbore`, `steelbore-blue`, `steelbore-blackpinkpanther`, `steelbore-matrixgreen`, `steelbore-navywhite`, `tokyonight`, `steelbore-hanzosteel` — each with its `-high-contrast` sibling, plus `steelbore-mono`. Fifteen themes | Every one binds the same eleven role tokens, so a theme layer that reads `steelbore.toml` registers them in a loop. A declaration can then always be answered |
 | **MAY register** | `steelbore-classic` and `steelbore-classic-high-contrast` | Classic keeps the legacy six-role contract (§11.2) and defines no surface class, so it is registrable only by an application that implements that contract as well |
 | **MUST NOT register** | A §11.5 fidelity palette, other than as an explicitly user-selectable extra | §11.5 bars adoption, and this section is not a route around it |
 
-Three of the thirteen were already required — the project’s own palette
+Three of the fifteen were already required — the project’s own palette
 by §11.4, its `-high-contrast` sibling by §11.1.1, and `steelbore-mono`
-by §11.1.1 — so this section adds ten themes, all of them already
+by §11.1.1 — so this section adds twelve themes, all of them already
 written out in `steelbore.toml`.
 
 **Registering is not defaulting.** The default remains the project’s
@@ -2829,7 +2881,7 @@ A project claims conformance in `README.md`, in one line, naming the
 standard version, the category, and whether the claim is full or
 tailored:
 
-    Conforms to The Steelbore Standard v2.04 --- Category B, tailored
+    Conforms to The Steelbore Standard v2.05 --- Category B, tailored
     (§22, §23; see COMPLIANCE.md).
 
 **Full conformance** means every applicable clause is applied and the
@@ -3579,7 +3631,7 @@ Before finalising **any** Spacecraft Software artifact, mentally verify:
   system declaration, then the platform color scheme, then the project’s
   §11.4 default), then variant overlay (a pinned variant, then
   `NO_COLOR` ⇒ `steelbore-mono`, then §18.1 accessible mode, then
-  platform high contrast); the registered set covers §11.6.1’s thirteen
+  platform high contrast); the registered set covers §11.6.1’s fifteen
   eleven-role themes; an unknown or unregistered slug falls through
   rather than failing; palette switches are atomic and whole-surface and
   carry the new canvas; resolved theme and deciding source reported