slipwai 1.3.0.dev41__tar.gz → 1.3.0.dev44__tar.gz

{slipwai-1.3.0.dev41 → slipwai-1.3.0.dev44}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: slipwai
-Version: 1.3.0.dev41
+Version: 1.3.0.dev44
 Summary: One-shot scaffolder for product monorepos: a walking skeleton, a verify gate, a path to production, and a repository set up for coding agents.
 Project-URL: Homepage, https://github.com/ROBCOATVG/slipwai
 Project-URL: Repository, https://git.treyco.dev/ROBCOATVG/slipwai

slipwai-1.3.0.dev44/VERSION

@@ -0,0 +1 @@
+1.3.0.dev44

{slipwai-1.3.0.dev41 → slipwai-1.3.0.dev44}/assets/profiles/event-modelling/.specify/presets/event-modelling/templates/tasks-template.md

@@ -144,7 +144,7 @@ task whose GREEN would be empty — a proof over behaviour an earlier task built
 folds into the task that produces the behaviour it guards.
 
 - [ ] T033 [US1] **Happy path.** RED: boundary acceptance for the happy path, entering through the use case, asserting on what is observable there. The route gets its own `tests/edge/` test for parse, delegate, and outcome-to-status — it is a translation, not where the rule is proved. GREEN: the minimum that satisfies it — the event schema(s) this one scenario needs, `initialState` and `evolve`, `decide` for the one command, the driving port returning discriminated outcomes, the use case (load, fold, decide, append with expected version), the route handler, and the composition wiring
-- [ ] T034 [US1] **The white box, in its main state.** *Delete these three tasks only if this slice has no `ui` frame — which for a `state-change` or `state-view` slice means the model is wrong, not that there is no screen.* RED: a test at the project's UI level drives the surface the way its actor does — type into the labelled fields, click the button — and asserts what the actor sees. GREEN: the screen. **If the `ui` frame has `mockups`, that state's mock is the build target**; open it and build to it. **If it has none, design it here** — then commit the wireframe under `docs/event-model/mockups/` and add its `mockups` entry to the frame in the same commit, because a screen whose states are recorded nowhere is a screen whose gaps nobody can see. An HTTP test through the route is **not** evidence about this task; load `front-end-testing` (and `react-testing` if the project is React) for the lightest harness that proves a browser-observable claim
+- [ ] T034 [US1] **The white box, in its main state.** *Delete these three tasks only if this slice has no `ui` frame — which for a `state-change` or `state-view` slice means the model is wrong, not that there is no screen.* RED: a test at the project's UI level drives the surface the way its actor does — type into the labelled fields, click the button — and asserts what the actor sees. GREEN: the screen. **If the `ui` frame has `mockups`, that state's mock is the build target**; open it and build to it. **If it has none, design it here** — then commit the wireframe under `docs/event-model/mockups/` and add its `mockups` entry to the frame in the same commit, because a screen whose states are recorded nowhere is a screen whose gaps nobody can see. An HTTP test through the route is **not** evidence about this task; load `front-end-testing` (and `react-testing` if the project is React) for the lightest harness that proves a browser-observable claim. **Its design is part of this task, not a follow-on**: before the first RED, `/drive`'s *Screen design* rung — `docs/design.md`, then `skills/frontend-design`'s second pass over the plan; before the demo, its *Design review* rung — the rendered screen, screenshot per state, read against `skills/web-interface-guidelines` — each with whatever an extension block in `AGENTS.md` adds to that rung. A green gate is not the review. Both write their line under `## Design review` below
 - [ ] T035 [US1] **Every other state of the screen.** One increment per state — empty, error, submitting, forbidden, whatever the screen can actually be in. RED at the UI level per state, GREEN the rendering it needs. These are where the unmodelled states surface: a screen with one design has three states nobody decided. Each one ends up in `mockups` too, so the model carries what the screen can be rather than what somebody remembered to draw
 - [ ] T036 [US1] **The screen reaches the command.** RED: submitting drives the driving adapter with the actor's input and renders each outcome the use case can return — accepted, business rejection, schema failure. GREEN: the wiring. **If the path beneath the screen is not finished in this slice, the screen still ships** — its submit reaches whatever exists and its states are still built and tested. A white box deferred to a later slice makes this slice a layer, and Principle V's slice independence is about seeding from synthetic events, never about leaving the actor with nothing to use
 - [ ] T037 [US1] **First business rejection.** RED: one rejection at the boundary, with its reason and any detail the caller needs to explain it. GREEN: extend `decide` to reject in business vocabulary. **Each further rejection is its own increment** — repeat this cycle per rule, do not add them as a batch
@@ -174,6 +174,13 @@ not delay feedback on working behaviour.
 
 ---
 
+## Design review
+
+*Written by `/drive`, not by hand: a `Designed:` line per screen before its first RED, a `Reviewed:` line per
+screen before the demo — or `No screen in this slice`. A screen missing either line is not ready to show.*
+
+---
+
 ## Phase 4: Polish
 
 - [ ] Run `/adversary` and record the full attempt log; fix every confirmed violation of an existing

{slipwai-1.3.0.dev41 → slipwai-1.3.0.dev44}/assets/toolkit/scripts/extensions/uipro/init.py

@@ -61,9 +61,9 @@ GUIDANCE = f"""
 ## UI/UX Pro Max
 `skills/{SKILL}/` is a design-system generator that runs offline: a search over local data that answers
 which pattern, style, palette, type pairing, chart types and UX rules fit a product of this kind. Reach for
-it **before the first screen of a slice that `docs/design.md` has no decision for**, and for one focused
-question — a component, a chart, a stack rule — with a single `--domain` or `--stack` search. Read the
-skill's own `SKILL.md` for the query contract; the short form is:
+it **at `/drive`'s *Screen design* rung, for a screen `docs/design.md` has no decision for**, and for
+one focused question — a component, a chart, a stack rule — with a single `--domain` or `--stack` search.
+Read the skill's own `SKILL.md` for the query contract; the short form is:
 
     python3 skills/{SKILL}/scripts/search.py "<product type> <industry> <keywords>" --design-system \\
         -p "<project name>" --persist --output-dir .
@@ -73,7 +73,8 @@ made from, and the input the browser app's `tokens.css` is filled from — but i
 `docs/design.md` stays the page every slice with a screen reads first: write what was chosen and why
 there, in the same commit as the tokens, link the `MASTER.md` it came from, and where the two disagree the
 page wins. Then take the plan through `skills/frontend-design`'s second pass — the review against the
-brief for defaults that would appear whatever the product — before writing any code.
+brief for defaults that would appear whatever the product — before writing any code, and say on the screen's
+`Designed:` line which search the decision came from.
 
 **Check you can reach it before you trust it.** The search is standard-library Python 3 and travels with
 the skill, so the only two ways it is unreachable are a checkout without the skill and a machine without

{slipwai-1.3.0.dev41 → slipwai-1.3.0.dev44}/assets/toolkit/scripts/extensions/ux-gates/init.py

@@ -80,11 +80,14 @@ the gates in it that are objective: a screen either passes or it does not.
   `scripts/check-ux-gates.py` or anything under `{KIT_DIR}/`: fix the screen, install the browser, or
   report the gate's own words.
 
-**Run `make check-ux-gates` before the demo stop of any slice with a screen**, and fix what it finds
-rather than carrying it as a note. For the judgement the gates cannot make, the kit's checklists are files:
-`{KIT_DIR}/accessibility/wcag-checklist.md` (POUR-organised, P0 first) and
-`{KIT_DIR}/workflows/design-review.md` (six weighted dimensions and Nielsen's heuristics), read alongside
-`skills/web-interface-guidelines`. Never state a contrast ratio you did not measure; the gates print theirs.
+**What this adds to `/drive`'s *Design review* rung.** Run `make check-ux-gates` first and fix what it
+finds rather than carrying it as a note. Then the review itself, which the gates are not: render the screen
+from its preview under `screens/` where it has one, and read the screenshots against
+`{KIT_DIR}/workflows/design-review.md` (six weighted dimensions and Nielsen's heuristics) and
+`{KIT_DIR}/accessibility/wcag-checklist.md` (POUR-organised, P0 first) as well as
+`skills/web-interface-guidelines`, and name all three on the screen's `Reviewed:` line. Every gate green is
+the objective half: screens have passed all of them and still shipped browser-default links and a raw
+identifier. Never state a contrast ratio you did not measure; the gates print theirs.
 
 **Check you can reach it before you trust it.** `{KIT_DIR}/` is ignored by Git and installed by this
 extension, so a fresh clone, a container or a CI runner has the pointer and not the kit. When

slipwai-1.3.0.dev44/changelog.d/design-review-is-a-stage.md

@@ -0,0 +1,28 @@
+PATCH
+
+**A slice with a screen now has its design decided before it is built and reviewed on the rendered screen
+before the demo, as two `/drive` rungs, not as a sentence nothing asked anyone to act on.** Three new screens
+reached a demo with every `check-ux-gates` gate green and still showed default-blue links, labels crammed
+against their fields, a raw UUID and a diagram drawn as a bare rectangle: the design skills were installed and
+`AGENTS.md` named them, but no stage of the ladder asked for them, so a delegate briefed from the plan styled
+from the tokens, ran the gates and stopped. Where the project has a browser app:
+
+- **Screen design**, between *Plan and tasks* and *Implementation*: `docs/design.md` holds the decision each
+  screen needs, `skills/frontend-design`'s second pass has been over the plan, and `tasks.md` records a
+  `Designed:` line per screen under `## Design review`.
+- **Design review**, between *Implementation* and *Convergence*: each screen rendered, a screenshot per state,
+  read against `skills/web-interface-guidelines`, every finding fixed or given its reason on a `Reviewed:`
+  line. A green gate is evidence for this rung, never the rung.
+- A slice with no screen says `No screen in this slice` once, and both rungs are done.
+
+The ladder names only what every browser app ships with. The `uipro` extension's `AGENTS.md` block now puts its
+search into *Screen design*, and the `ux-gates` block puts `make check-ux-gates` and the kit's `design-review.md`
+and `wcag-checklist.md` into *Design review*, so a project that did not adopt them reads about neither. The
+`drive-tasks` brief and the event-modelling tasks template carry the steps inside the styling task and leave the
+`## Design review` heading. The demo stop checks the record. Under `/cruise`, `drive-hand` also looks at every
+screen on its browser walk and writes what it sees as `design:` notes in the demo log's **Feedback**.
+
+**Catch-up.** `slipwai migrate` brings the ladder, the brief and the template. A slice already past
+*Implementation* whose `tasks.md` has no `## Design review` enters `/drive` at *Screen design*: write the
+`Designed:` lines for the screens that were built, then run the review. In a project that adopted `uipro` or
+`ux-gates`, run `make agents` once so its `AGENTS.md` block names the rung, and commit the result.

{slipwai-1.3.0.dev41 → slipwai-1.3.0.dev44}/src/slipwai/project/agents.py

@@ -22,6 +22,7 @@ from dataclasses import dataclass
 from ..layout import AT_ROOT, Layout
 from .converge_stage import levels
 from .cruise_agents import cruise_body, cruise_summary
+from .design_stage import tasks_brief as design_tasks_brief
 from .stage_models import AGENT, ANY, MANIFEST, NO_STAGE, STAGES
 
 # Where the canonical types live, beside `skills/` and `commands/`.
@@ -86,7 +87,7 @@ def summary(agent: Type) -> str:
 def body(agent: Type, layout: Layout) -> str:
     """The standing brief: what this type is for, what it may touch, what it returns, and what it hands back."""
     return {
-        "drive-tasks": """You turn one slice's finished plan into the ordered tasks that build it.
+        "drive-tasks": f"""You turn one slice's finished plan into the ordered tasks that build it.
 
 The plan, example map, data model and contracts are already written and authoritative. Add no requirement,
 resolve no open question and change no decision. Report a contradiction between them; never reconcile one.
@@ -104,8 +105,10 @@ the moment it is written.
 
 Cover **every layer the slice's patterns require** — domain logic alone is a component, not a vertical
 slice. Where the slice puts anything on a screen, its styling is a task here, naming the screen and where
-its styles come from. Writing each white box's states back as committed mockups is a task too, because
-`check-model` refuses an implemented slice without them.
+its styles come from. {design_tasks_brief()}
+
+Writing each white box's states back as committed mockups is a task too, because `check-model` refuses an
+implemented slice without them.
 
 Mark `[P]` wherever a task's files are disjoint from its siblings' — whether or not it adds production code —
 and nowhere else, and write the *Parallel opportunities* section that

{slipwai-1.3.0.dev41 → slipwai-1.3.0.dev44}/src/slipwai/project/commands.py

@@ -14,6 +14,7 @@ from .converge_stage import convergence_stage
 from .cruise import cruise_command, cruise_settings_command
 from .cruise_seat import cruise_status_command, cruise_stop_command, cruise_tell_command, cruise_watch_command
 from .demo_stop import demo_stop
+from .design_stage import PLAN_STYLING, with_design_rungs
 from .drive_adoption import adoption_ladder
 from .drive_settings import drive_settings_command, implementation_section
 from .existing import release_stage
@@ -35,12 +36,6 @@ def drive_command(
     # project whose browser app is `apps/portal` has no `apps/web` for this to point at.
     web = web_apps(apps)
     baseline = ", ".join(f"`{app.path}`" for app in web)
-    styling = (
-        """ Where the slice puts anything on a screen, its styling is one of the tasks written here rather
-   than a follow-on: name the screens it adds or changes and where each takes its styles from."""
-        if web
-        else ""
-    )
     stages = [
         """**Principles** — `.specify/memory/constitution.md` is ratified rather than absent, unfilled, or
    still the template `./init` installed, and `make check-constitution` passes. A passing gate alone is not
@@ -121,7 +116,7 @@ def drive_command(
    version's requirement — cites the artefact it was read from: the library's documentation at the pinned
    version, its source, a run against it. A statement with no citation reads *assumed*, and a plan does not
    rest on it."""
-        + context_decision + styling,
+        + context_decision + (PLAN_STYLING if web else ""),
         """**Implementation** — tasks remain unchecked. Run the installed Spec Kit implement command."""
         + (
             f""" A screen this slice
@@ -134,6 +129,7 @@ def drive_command(
         convergence_stage(),
         """**Demo** — the actor-visible path is ready to show.""",
     ]
+    stages = with_design_rungs(stages, baseline) if web else stages
     if adoption is not None:
         stages = adoption_ladder(stages, apps, layout)
     ladder = "\n".join(f"{index}. {stage}" for index, stage in enumerate(stages, start=1))

{slipwai-1.3.0.dev41 → slipwai-1.3.0.dev44}/src/slipwai/project/cruise_agents.py

@@ -105,8 +105,12 @@ Your verdict is one of three words, the ones `scripts/agents/benchmark.py end` a
 specification meant, with the example that shows it, which re-enters the ladder at the stage that owns the
 change; `implementation` — an example failed against what the plan promised, with the reproduction, which is a
 task. Feedback that is neither — a label, a colour, a layout — is a note for the next slice, never a reason
-to withhold acceptance. Say which examples passed and which did not; a verdict without them is a summary, and
-a summary is what the demo stop refuses to be.
+to withhold acceptance. **Look at every screen as well as using it**, since a person at the demo would: a
+browser-default link or control, a label crammed against its field, a value you were never meant to read (an
+identifier, an enum's spelling), a figure with no labels. Write each as `design:` in **Feedback** with its
+screenshot, and the session that delegated you sets it against the slice's `## Design review` record. Say
+which examples passed and which did not; a verdict without them is a summary, and a summary is what the demo
+stop refuses to be.
 
 Your writes are `{DEMO_LOG}` — one section per demo, in the shape that file shows — and the screenshots and
 responses under `{EVIDENCE}` it cites. You read and run anything; you edit no code, no test and no artifact of

{slipwai-1.3.0.dev41 → slipwai-1.3.0.dev44}/src/slipwai/project/demo_stop.py

@@ -51,11 +51,11 @@ STYLED = """**Before the demo, check every screen this slice adds or changes is
 project's own styles — `docs/design.md`, or the design notes in the constitution or under `specs/` — or, where
 the slice needs something those do not cover, the baseline stylesheet and design tokens in {baseline} extended
 rather than bypassed. A screen still on browser defaults is a reason not to demo yet: the actor is being asked
-whether the thing works, and an unstyled page answers a different question first. Then read the files the
-slice changed under the browser app against `skills/web-interface-guidelines` — labels, focus, forms, motion,
-typography, the anti-patterns it lists — and fix what it finds before the demo rather than carrying it as a
-note. Record both checks with the others, naming the screens, where their styles came from, and what the
-review found.
+whether the thing works, and an unstyled page answers a different question first. `tasks.md`'s
+`## Design review` is where that was checked: a `Designed:` and a `Reviewed:` line for every screen, the
+review read from screenshots against `skills/web-interface-guidelines` and every finding fixed or given its
+reason. A screen missing either line goes back to the rung that writes it rather than to the actor. Record both
+checks with the others, naming the screens, where their styles came from, and what the review found.
 
 """
 DEMO_STOP = """### What the demo stop has to contain

slipwai-1.3.0.dev44/src/slipwai/project/design_stage.py

@@ -0,0 +1,72 @@
+"""The two design rungs of `commands/drive.md`: the screen decided before it is built, and reviewed rendered
+before the demo.
+
+Its own module for the reason `converge_stage.py` is: the text exists because of evidence. Three new screens —
+an editor, a list and a printable sheet — reached their demo with every `check-ux-gates` gate green, and still
+showed default-blue links, labels crammed against their fields, a raw UUID and a diagram drawn as a bare
+rectangle. The design skills were installed and `AGENTS.md` named them; no rung asked for them to run, so a
+delegate briefed from the plan styled from the tokens, ran the gates, and read the silence conservatively. So
+the review is a rung, with a record in `tasks.md` like the convergence verdict, which is what makes it
+impossible to skip silently and unnecessary to repeat.
+
+The rungs name only what every project with a browser app carries: `skills/frontend-design` and
+`skills/web-interface-guidelines`. An extension that brings more to a rung — `uipro`'s search before the
+build, `ux-gates`' gates and checklists before the demo — says so in its own `AGENTS.md` block, written when
+it is adopted, so a project that never adopted one never reads about it. Absent where there is no browser app:
+a rung nothing can fail teaches the reader to skim the rest.
+"""
+from __future__ import annotations
+
+# What the *Plan and tasks* rung adds where there is a browser app: styling is one of the slice's tasks.
+PLAN_STYLING = """ Where the slice puts anything on a screen, its styling is one of the tasks written here rather
+   than a follow-on: name the screens it adds or changes and where each takes its styles from."""
+
+
+def screen_design_stage(baseline: str) -> str:
+    """The `**Screen design**` rung, between the plan and the implementation: what each screen is to look like."""
+    return f"""**Screen design** — `tasks.md` has a `## Design review` heading with a `Designed:` line for
+   every screen the slice adds or changes, or the one line `No screen in this slice`. Otherwise decide each
+   screen before any code for it is written. Read `docs/design.md` first, and write into it any decision this
+   screen needs that it does not hold — a pattern, a layout, a component — doing what an extension block in
+   `AGENTS.md` adds to this rung as well. Then take the plan's screens through `skills/frontend-design`'s
+   second pass — the review against the brief for the defaults that would appear whatever the product — and
+   write what it changed into the plan. The line names the screen, where its styles come from
+   (`docs/design.md`, the constitution's design notes, or the baseline in {baseline} extended) and what the
+   second pass changed, or that it changed nothing and why. A screen with no decision is built on the
+   browser's, and the implementer reads the silence as permission."""
+
+
+def design_review_stage(baseline: str) -> str:
+    """The `**Design review**` rung, after implementation and before convergence: the screens looked at."""
+    return f"""**Design review** — the `## Design review` section has a `Reviewed:` line for every screen the
+   slice adds or changes, or says `No screen in this slice`. Otherwise review what the actor will see, not the
+   source: render each screen in {baseline} — the running app, reached the way `skills/run-the-app` records —
+   take a screenshot of each state it can be in, and read the screenshots against
+   `skills/web-interface-guidelines`, doing what an extension block in `AGENTS.md` adds to this rung as well.
+   A passing gate is evidence for this stage, never the stage: screens with every automated check green have
+   still shipped default-blue links, labels crammed against their fields, a raw identifier shown to the actor
+   and a diagram drawn as a bare rectangle. So look for what a check cannot see — browser defaults anywhere,
+   the space between a label and its field, a value the actor was never meant to read (an identifier, an
+   enum's spelling, a raw timestamp), a figure with no labels, an empty state with nothing in it, one thing
+   styled two ways. Fix each finding in this slice, or record it with a reason on the screen's line; a finding
+   with neither is a demo that shows it. The line names the screen, the screenshots under
+   `specs/<feature>/slices/<id>/design/`, what the review read, and what was fixed or recorded. A later task
+   that changes a reviewed screen adds a line for it rather than leaving the old one to speak for it."""
+
+
+def tasks_brief() -> str:
+    """What the tasks delegate writes into `tasks.md` for a slice with a screen, inside its styling task."""
+    return """The styling task names the design steps inside it, so a brief built from it
+carries them: `skills/frontend-design`'s second pass over the plan before any code, and the review of the
+rendered screens against `skills/web-interface-guidelines` before the demo — each with whatever an extension
+block in `AGENTS.md` adds to `/drive`'s *Screen design* or *Design review* rung. Leave a `## Design review`
+heading for the `Designed:` and `Reviewed:` lines those rungs write, or `No screen in this slice` under it
+where the slice has none."""
+
+
+def with_design_rungs(stages: list[str], baseline: str) -> list[str]:
+    """The ladder with *Screen design* before *Implementation* and *Design review* after it — around the
+    implementation rather than after convergence, because the review's fixes are code converge should see, and
+    the screen is decided before a delegate builds it on the browser's defaults."""
+    at = next(index for index, stage in enumerate(stages) if stage.startswith("**Implementation**"))
+    return [*stages[:at], screen_design_stage(baseline), stages[at], design_review_stage(baseline), *stages[at + 1:]]

slipwai-1.3.0.dev41/VERSION

@@ -1 +0,0 @@
-1.3.0.dev41