Toilville/toilville-design

Watch

Fork 0

SPELWork dashboards: sketch the three main dashboards (spec Part 1 §6) #171

New issue

Closed

opened 2026-09-28 20:29:22 +00:00 by forge-ci · 3 comments

forge-ci commented

2026-09-28 20:29:22 +00:00

Member

Section 6 of spelwork-dashboard-design-part1.md is still marked not started. The brief asks for three dashboards:

Worker health
A task in progress
System-wide problems

The spec planned these for after §3 (warning colours) and §4 (step colours, #172). They depend on those, but sketches can start with the proposed values and be updated later.

Question first

Forge wish ff0a357e ("deliverable: SPELWork dashboard sketches — Part 2") is marked completed, but there's no Part 2 file in the repo. If Part 2 was delivered somewhere else (Slack, email, an Affinity file), commit it under Brand/specs/spelwork/ and use it as the starting point.

Acceptance criteria

One sketch per dashboard, using the §3 warning states, the §4 step colours, and the §5 tooltip rules.
Sketches committed under Brand/specs/spelwork/ (for example as spelwork-dashboard-design-part2.md plus images).
Colours come from token names, not raw hex.

Section 6 of [`spelwork-dashboard-design-part1.md`](https://git.toilville.dev/Toilville/toilville-design/src/branch/main/Brand/specs/spelwork/spelwork-dashboard-design-part1.md) is still marked **not started**. The brief asks for three dashboards: 1. **Worker health** 2. **A task in progress** 3. **System-wide problems** The spec planned these for after §3 (warning colours) and §4 (step colours, #172). They depend on those, but sketches can start with the proposed values and be updated later. ## Question first Forge wish `ff0a357e` ("deliverable: SPELWork dashboard sketches — Part 2") is marked completed, but there's no Part 2 file in the repo. If Part 2 was delivered somewhere else (Slack, email, an Affinity file), commit it under `Brand/specs/spelwork/` and use it as the starting point. ## Acceptance criteria - [ ] One sketch per dashboard, using the §3 warning states, the §4 step colours, and the §5 tooltip rules. - [ ] Sketches committed under `Brand/specs/spelwork/` (for example as `spelwork-dashboard-design-part2.md` plus images). - [ ] Colours come from token names, not raw hex.

ville was assigned by forge-ci

2026-09-28 20:29:22 +00:00

peterswimm commented

2026-10-16 19:16:25 +00:00

Owner

@ville can you work on this next week

ville referenced this issue

2026-10-22 13:39:07 +00:00

docs(spelwork): Part 2 — sketches for the three §6 dashboards #224

ville commented

2026-10-22 14:04:13 +00:00

Member

Part 1 §6 is drawn. One sketch per dashboard: worker health, a task in progress, system-wide problems.

They are built from the real SPELWork tokens in dist/spelwork/skin.css and the real plates — press.ruled-panel-fixed for the header rule, plate.ui.line-horizontal for every band rule, press.hatched-frame for the detail panel. No new card, spacing, type or icon system, and no invented hex.

Proposed as Brand/specs/spelwork/spelwork-dashboard-design-part2.md, with the three figures under Brand/specs/spelwork/spelwork-dashboard-part2/.

The approach

§6 was blocked behind §3 and §4. Both are now decided (#174 and #172, approved 2026-10-21), but the token entries are not yet written. Each board is drawn so it reads without the missing tokens, and the missing thing is named on the sketch.

Worker health uses no severity colour. State is carried by a glyph, a drawn rule weight and the state word — which §3 asks for anyway. It shows four severity levels, with old set apart as the stale, data-freshness state. A task in progress uses the six confirmed steps (Foundation, Intent, Structure, Execution, Scale, Outcome) and no step colour. Each board carries an annotation block naming what was left out and why.

What the contracts actually gave

The second and third boards turned out to be better supplied than expected.

ProgressBlock and ProgressStep carry label, status, value, detail and steps — enough for the whole task spine. AttentionSummary is a shipped three-feed problem aggregation with a hasAttention boolean, and its own comment sanctions composing it from existing signals. LineageEntryBlock, SafetyDecisionRecord and SyncState supply the evidence rows.

Everything on the boards comes from those. Nothing supplies a duration, a throughput, an error rate, a queue depth or a trend, so none appears.

Findings

The severity model is decided (#174); two tokens are missing. Four levels plus a separate stale state: fine = color.accent.success, slow = color.accent.warning, broken = color.accent.error, very serious = color.accent.critical (new), old = a stale neutral on color.neutral.warm-* (new). color.safety.* is rejected for worker health. Still to be drafted: color.accent.critical, the stale token and its exact name, and real dark values for the baseline success, warning and error. SPELWork's skin emits no accent.* tokens today.
No severity icons exist. The spel.* registry has no severity family. The glyphs on the sketch are provisional.
Three tokens the shipped safety renderer resolves are not in the SPELWork palette — accent.consent, accent.error, accent.warning-text. safety_decision_block_renderer.dart uses all three; dist/spelwork/skin.css emits none.
override has no colour token. It is the fourth safety_decision value and the safety palette has three.
SyncStatus.conflict never reaches triage. AttentionSummary queries uploading only, so conflict records are absent from the third board by construction. Recorded here, not solved.
§1 of Part 1 is stale. It lists the background as #FFFFFF/#121212 and text as #111827. The live SPELWork values are #FEFEFE and #1A1A1A.
SPELWork has no dark theme. The build emits a light :root only, so §3's dark column has nothing to apply to.

Still unresolved

#172 is confirmed: the steps are the six dimension stages, identified by spel.stage.0 to spel.stage.5, with one sequential brand-blue ramp for colour. The ramp's tokens are not drafted, so no step colour is drawn.

The severity and step-ramp token entries, the five state icons, the lifecycle icons, the product mapping for the three missing accent tokens, and whether blockers ever get a severity of their own are open. None is decided here.

**Part 1 §6 is drawn. One sketch per dashboard: worker health, a task in progress, system-wide problems.** They are built from the real SPELWork tokens in `dist/spelwork/skin.css` and the real plates — `press.ruled-panel-fixed` for the header rule, `plate.ui.line-horizontal` for every band rule, `press.hatched-frame` for the detail panel. No new card, spacing, type or icon system, and no invented hex. Proposed as `Brand/specs/spelwork/spelwork-dashboard-design-part2.md`, with the three figures under `Brand/specs/spelwork/spelwork-dashboard-part2/`. ## The approach §6 was blocked behind §3 and §4. Both are now decided (#174 and #172, approved 2026-10-21), but the token entries are not yet written. Each board is drawn so it reads *without* the missing tokens, and the missing thing is named on the sketch. Worker health uses no severity colour. State is carried by a glyph, a drawn rule weight and the state word — which §3 asks for anyway. It shows four severity levels, with `old` set apart as the stale, data-freshness state. A task in progress uses the six confirmed steps (Foundation, Intent, Structure, Execution, Scale, Outcome) and no step colour. Each board carries an annotation block naming what was left out and why. ## What the contracts actually gave The second and third boards turned out to be better supplied than expected. `ProgressBlock` and `ProgressStep` carry label, status, value, detail and steps — enough for the whole task spine. `AttentionSummary` is a shipped three-feed problem aggregation with a `hasAttention` boolean, and its own comment sanctions composing it from existing signals. `LineageEntryBlock`, `SafetyDecisionRecord` and `SyncState` supply the evidence rows. Everything on the boards comes from those. Nothing supplies a duration, a throughput, an error rate, a queue depth or a trend, so none appears. ## Findings 1. **The severity model is decided (#174); two tokens are missing.** Four levels plus a separate stale state: fine = `color.accent.success`, slow = `color.accent.warning`, broken = `color.accent.error`, very serious = `color.accent.critical` (new), old = a stale neutral on `color.neutral.warm-*` (new). `color.safety.*` is rejected for worker health. Still to be drafted: `color.accent.critical`, the stale token and its exact name, and real dark values for the baseline success, warning and error. SPELWork's skin emits no `accent.*` tokens today. 2. **No severity icons exist.** The `spel.*` registry has no severity family. The glyphs on the sketch are provisional. 3. **Three tokens the shipped safety renderer resolves are not in the SPELWork palette** — `accent.consent`, `accent.error`, `accent.warning-text`. `safety_decision_block_renderer.dart` uses all three; `dist/spelwork/skin.css` emits none. 4. **`override` has no colour token.** It is the fourth `safety_decision` value and the safety palette has three. 5. **`SyncStatus.conflict` never reaches triage.** `AttentionSummary` queries `uploading` only, so conflict records are absent from the third board by construction. Recorded here, not solved. 6. **§1 of Part 1 is stale.** It lists the background as `#FFFFFF`/`#121212` and text as `#111827`. The live SPELWork values are `#FEFEFE` and `#1A1A1A`. 7. **SPELWork has no dark theme.** The build emits a light `:root` only, so §3's dark column has nothing to apply to. ## Still unresolved #172 is confirmed: the steps are the six dimension stages, identified by `spel.stage.0` to `spel.stage.5`, with one sequential brand-blue ramp for colour. The ramp's tokens are not drafted, so no step colour is drawn. The severity and step-ramp token entries, the five state icons, the lifecycle icons, the product mapping for the three missing accent tokens, and whether blockers ever get a severity of their own are open. None is decided here.

ville referenced this issue

2026-10-23 20:38:55 +00:00

docs(spelwork): Part 2 token status after #225 and #226 #227

peterswimm referenced this issue

2026-10-27 23:06:24 +00:00

SPELWork tokens: the three questions Part 1 leaves open after #172/#173/#174 #234

peterswimm commented

2026-10-27 23:06:59 +00:00

Owner

Closing — §6 is delivered, as Part 2.

All three sketches exist with their figures and specifications in Brand/specs/spelwork/spelwork-dashboard-design-part2.md:

Dashboard	Section	Figure
Worker health	§1	`spelwork-dashboard-part2/worker-health.png`
A task in progress	§2	`spelwork-dashboard-part2/task-in-progress.png`
System-wide problems	§3	`spelwork-dashboard-part2/system-wide-problems.png`

Each carries Specified / Contract, Proposed and Open subsections, §4 records the patterns reused across all three, and the icon-status table marks honestly which glyphs are placeholders drawn for the mockup versus registered house-style art. §3.3 is a good catch — Worker health is a roster, system-wide problems is not that at a larger scale.

One loose end, not blocking: Part 1 §6 still reads "Status: not started." That is now wrong and reads as unstarted work to anyone who opens Part 1 first. Recorded in #234 as a one-line fix for the next time that file is touched.

**Closing — §6 is delivered, as Part 2.** All three sketches exist with their figures and specifications in `Brand/specs/spelwork/spelwork-dashboard-design-part2.md`: | Dashboard | Section | Figure | |---|---|---| | Worker health | §1 | `spelwork-dashboard-part2/worker-health.png` | | A task in progress | §2 | `spelwork-dashboard-part2/task-in-progress.png` | | System-wide problems | §3 | `spelwork-dashboard-part2/system-wide-problems.png` | Each carries Specified / Contract, Proposed and Open subsections, §4 records the patterns reused across all three, and the icon-status table marks honestly which glyphs are placeholders drawn for the mockup versus registered house-style art. §3.3 is a good catch — Worker health is a roster, system-wide problems is not that at a larger scale. One loose end, not blocking: **Part 1 §6 still reads "Status: not started."** That is now wrong and reads as unstarted work to anyone who opens Part 1 first. Recorded in #234 as a one-line fix for the next time that file is touched.

peterswimm closed this issue

2026-10-27 23:06:59 +00:00