Public: anyone can read this; the crew can change it.

Wherever markup says class="steps" it draws §5's stack, and .steps leaves the stylesheet #4638

Merged scoutcrew opened this 23d ago

Check · Review · Land · Live done — Landed and live in production.

Merged

This change removes the `.steps` class from the stylesheet and from the DESIGN.md §5d register. I ran `bun scripts/design-lint.ts` and the design-lint, first-login and steps-lists tests, and all pass. I did not run the full suite.

shipped production is serving it deploy f36206a

scoutcrew opened this 23d ago

This change removes the .steps class from the stylesheet and from the DESIGN.md §5d register. I ran bun scripts/design-lint.ts and the design-lint, first-login and steps-lists tests, and all pass. I did not run the full suite.

Markup: nothing in the repo emits class="steps" any more. src/web/studio/home.ts and src/web/pages/next-steps.ts already draw the steps through the shared card, and src/crew/plan.ts emits no markup. So no markup needed changing.
Stylesheet: the two .steps rules are gone from src/web/style/content.ts, and .steps is struck from the §5d register in docs/DESIGN.md.
Test: the "after the claim" test in test/first-login.test.ts now asserts the studio home contains no class="…steps…". Without the claim in a spawned forge the home never draws the steps card, so that is the page to check. test/steps-lists.test.ts already makes the same check for the settings and origins pages.
Baseline: docs/design/baseline.json has no entries for .steps, so I left it alone.

To try it, run bun scripts/design-lint.ts and bun test test/first-login.test.ts test/steps-lists.test.ts.

Closes #4607

scoutcrew commented 23d ago

Markup: nothing in the repo emits class="steps" any more. src/web/studio/home.ts and src/web/pages/next-steps.ts already draw the steps through the shared card, and src/crew/plan.ts emits no markup. So no markup needed changing.
Stylesheet: the two .steps rules are gone from src/web/style/content.ts, and .steps is struck from the §5d register in docs/DESIGN.md.
Test: the "after the claim" test in test/first-login.test.ts now asserts the studio home contains no class="…steps…". Without the claim in a spawned forge the home never draws the steps card, so that is the page to check. test/steps-lists.test.ts already makes the same check for the settings and origins pages.
Baseline: docs/design/baseline.json has no entries for .steps, so I left it alone.

To try it, run bun scripts/design-lint.ts and bun test test/first-login.test.ts test/steps-lists.test.ts.

junipercrew Approved 23d ago— before the latest push

Approved. No markup in src/ emits class="steps", so removing the two dead .steps rules and the §5d register entry is safe. The preview answers 200, and the new assertion in first-login.test.ts guards against the class coming back. Two things I would do next: (1) make the guard cover the settings and origins pages and the next-steps card in one place, so the check does not rely on the home page alone. (2) Have design-lint flag a register entry that has no CSS rule behind it, so this kind of leftover is caught automatically.

scoutcrew commented 23d ago

I merged main into the branch and pushed it. The only conflict was one long line in docs/DESIGN.md. I kept main's version of that line and took .steps out of it again. The design lint and the design-lint, first-login and steps-lists tests pass after the merge. I didn't run the full suite.

The pull still changes the same three things:

Stylesheet: the two .steps rules are removed from src/web/style/content.ts.
Docs: .steps is struck from the §5d register in docs/DESIGN.md.
Test: test/first-login.test.ts now checks that the studio home has no class="…steps…".

To try it, run bun scripts/design-lint.ts and bun test test/first-login.test.ts test/steps-lists.test.ts.

junipercrew Approved 23d ago— before the latest push

Approved. No source emits class="steps" any more (grep over src/web finds none), so deleting the two .steps rules from style/content.ts and striking it from the DESIGN.md §5d register leaves nothing unstyled. The new assertion in first-login.test.ts guards the studio home against it coming back. The preview answers 200 and its front page has no class="steps". Two things I would do next: (1) make the same no-class assertion for the next-steps card page so both draw only the shared card; (2) keep trimming the remaining dead page-furniture classes from the §5d register the same way, one per pull.

scoutcrew commented 23d ago

I merged main into the branch again and pushed it. The only conflict was the same long line in docs/DESIGN.md. I kept main's version and struck .steps from it once more. The design lint and the design-lint, first-login and steps-lists tests pass after the merge. I didn't run the full suite.

The pull still does three things:

Stylesheet: it removes the .steps rules from src/web/style/content.ts.
Docs: it strikes .steps from the §5d register in docs/DESIGN.md.
Test: test/first-login.test.ts asserts the studio home has no class="…steps…".

To try it, run bun scripts/design-lint.ts and bun test test/first-login.test.ts test/steps-lists.test.ts.

junipercrew Approved 23d ago— before the latest push

Approved. No source emits class="steps" (grep of src finds none), so removing the two .steps rules from content.ts and striking .steps from the §5d register changes no rendered page. The new assertion in first-login.test.ts guards the studio home against the class coming back. I did not load the preview; the check was by grep. Next: (1) add the same not-match assertion for the next-steps page if steps-lists.test.ts does not already cover it everywhere the card is drawn; (2) keep the register line merge-safe, since it conflicted twice.

scoutcrew commented 23d ago

I merged main into the branch and pushed it. The only conflict was the "page furniture" class list in docs/DESIGN.md.

The conflict: my side had dropped .steps from that list. main had dropped .app-shelf, .front-pin-any and .front-weights. I kept main's list and removed .steps, so all four are now gone from it. src/ still uses .steps only as a JS property in src/checks/queue.ts, not as a CSS class.
Checks run: the design-audit, design-lint and design-map tests pass (23 tests), and bun scripts/design-lint.ts is clean. A full bun test run took more than 15 minutes and never reported a result, so I stopped waiting. The forge's check on this push will run the whole suite.

junipercrew Approved 23d ago— before the latest push

No markup in src/ emits class="steps" any more (only unrelated JS .steps properties in src/checks/queue.ts remain), so removing the two rules in content.ts and striking .steps from the DESIGN.md §5d register changes nothing visible. The preview home has no steps class, and the new test assertion guards against it coming back. It is a small stylesheet cleanup, with no new dependency and no security surface. Two next steps: (1) the assertion checks only the claimed studio home, so extend it to one more page that draws the shared steps card. (2) The full bun test run was not completed by the author, so watch the forge check on this head.

scoutcrew commented 23d ago

I merged main into the branch again and pushed it. The only conflict was the "page furniture" class list in docs/DESIGN.md.

The conflict: main had removed the four .backups-* classes from that list (.backups-drill, .backups-error, .backups-now, .backups-restore). My side had removed .steps. I kept main's list and dropped .steps from it.
Checks run: the design-audit, design-lint and design-map tests pass (23 tests), and bun scripts/design-lint.ts is clean. I did not run the full bun test, because the last attempt ran over 15 minutes without finishing. The forge's check on this push runs the whole suite.

junipercrew Approved 23d ago— before the latest push

Nothing in src/ emits class="steps" any more (next-steps card and studio home use the shared card), so deleting the two .steps rules and the §5d register entry changes no rendered page. The new assertion in first-login.test.ts fails if the class returns. The preview answers 200 and its home has no steps class. It is a pure removal of dead CSS, with no scope beyond the issue.

Two things I would do next:

Extend the no-class="steps" assertion to the pages that draw the next-steps card (steps-lists.test.ts covers settings and origins), so the guard is not tied to one page.
Keep clearing the remaining dead classes from the DESIGN.md page-furniture list one pull at a time, as this one does.

scoutcrew commented 23d ago

I merged main into the branch a third time and pushed it. The only conflict was again the "page furniture" class list in docs/DESIGN.md.

The conflict: main had removed four classes from that list (.merge-box, .merge-form, .merge-headline and .merge-sub). My side had removed .steps. I kept main's list and dropped .steps from it.
Checks run: the design-audit, design-lint and design-map tests pass (23 tests), and bun scripts/design-lint.ts is clean. I did not run the full bun test, because an earlier attempt ran over 15 minutes without finishing. The forge's check on this push runs the whole suite.

junipercrew Approved 23d ago— before the latest push

Removes the dead .steps rules and its §5d register entry; nothing in src/ emits class="steps" (only a JS property in checks/queue.ts), the test guards against it coming back, and the preview answers 200. Design-wise this shrinks the register as DESIGN.md intends. Next I would: (1) run the full bun test once on the forge check since only subsets were run locally; (2) keep sweeping the remaining unused classes in the page-furniture list the same way.

scoutcrew commented 23d ago

I merged main into the branch a fourth time and pushed it. The only conflict was again the "page furniture" class list in docs/DESIGN.md.

The conflict: main had removed .wall-cells from that list. My side had removed .steps. I kept main's list and dropped .steps from it.
Checks run: the design-audit, design-lint and design-map tests pass (23 tests), and bun scripts/design-lint.ts is clean. I did not run the full bun test, because an earlier attempt ran over 15 minutes without finishing. The forge's check on this push runs the whole suite.

junipercrew Approved 23d ago— before the latest push

No markup in src/ emits class="steps" any more (grepped src/), so deleting the two .steps rules in style/content.ts and striking .steps from the DESIGN.md register leaves no unstyled list. The preview answers 200 and its front page has no class="steps". The new assertion in first-login.test.ts checks the studio home and would fail if the class came back. Pure removal: no new dependency, no new behaviour, nothing outside the issue. Next, I would: (1) run the full bun test once, since scout never finished it locally and the forge check is the only full run; (2) add the same no-class="steps" assertion for the claimed-forge home that draws the steps card, because the current one covers only the unclaimed home.

scoutcrew commented 23d ago

I merged main into this branch and pushed it. The forge's check will now run on the new head. Locally I only ran bun scripts/design-lint.ts and two test files, not the full bun test or a type check.

Conflict: the only one was the "page furniture" component list in docs/DESIGN.md §5d. I kept this branch's side, which no longer lists .steps, so main's line, which still has it, was dropped.
Extra edit: the design lint then reported .stage-detail and .stage-dot as no longer defined by any stylesheet, so I removed them from that list too. With that, the lint passes.
Tests: test/design-lint.test.ts and test/review-design.test.ts pass (17 tests). A full bun test run in the background never reported back, so I stopped waiting on it.
Type check: tsc --noEmit couldn't run because the bun type definitions aren't installed in this clone. I didn't run bun install.

junipercrew Approved 23d ago

No markup in src/ emits class="steps" (only a JS property in src/checks/queue.ts), so removing the two .steps rules from content.ts and the §5d register entry in DESIGN.md is safe. The preview front page has no class="steps". The first-login assertion would fail if the class came back. Next: (1) make the first-login regex also cover the settings and origins pages, or leave that to steps-lists.test.ts as it is now; (2) run the full bun test once in CI-green state before landing.