feat(skills): six new ms-* skills

ms-archify (evidence-based architectural mapping), ms-sdlc,
ms-proactive-agent, ms-goal, ms-grill-me, ms-frontend-design.

skills/ms-archify/SKILL.md

@@ -0,0 +1,302 @@
+---
+name: ms-archify
+description: Architectural mapping with evidence — trace a system as built or as planned, render it with Archify, get it reviewed by an independent seat, and run gap analysis between the two.
+disable-model-invocation: false
+---
+
+# Mosaic Archify
+
+A map is a claim. The code (as built) or the plan document (as planned) is
+the truth. This skill is the method that keeps the two aligned so that a
+picture can be trusted by someone who did not draw it. Archify is the
+renderer; it proves that a page is well formed. It proves nothing about
+whether the edges are true. That part is human work, done the way described
+here.
+
+Use this skill for: an as-built map of a subsystem, a planned map of a design
+document, a gap map between the two, an extensibility review of a roadmap,
+or any inspection where the deliverable is "here is how the values actually
+flow, with citations."
+
+Do not use it for a sketch nobody will review. A map without a reviewer is a
+drawing, not evidence.
+
+## Roles
+
+Three seats, never collapsed into one:
+
+- **Author** traces, specifies, renders, and submits. The author never
+  approves their own map.
+- **Reviewer** is a different agent seat. The reviewer opens every citation
+  and rules per edge: confirmed, wrong, or unsupported. The reviewer does not
+  fix the map and does not draw.
+- **Lead** (the human) accepts or sends back. Design decisions are the
+  lead's; the lane records facts and recommendations, never rulings of its
+  own.
+
+Other agents are sources, not seats. Ask the developer who built the thing
+for facts ("where does this value cross into the container?"), record the
+answer with a timestamp, and cite the file they point you to, not their
+message. Two brains beat one; one brain deciding it is in charge is the
+failure mode.
+
+## Lane layout
+
+One directory per mapping effort, under the fleet lanes tree:
+
+```
+METHOD.md        the cycle and its amendments (this skill, specialised)
+TASKS.md         monotonic ledger: proposed -> accepted -> in-progress -> done / declined
+COMMS.md         append-only record of every message sent and received, with timestamps
+comms/           full bodies of review requests and verdicts
+DECISIONS.md     the lead's rulings, by question number
+FINDINGS.md      what the tools were measured to do, and adoption rules
+spec/            <map>.architecture.json and <map>.EVIDENCE.md
+out/             delivered HTML, deliver.json, visual-check.json, screenshots
+run/             live preview state: pid files, logs, README.md naming the current spec
+```
+
+Rules for these files:
+
+- TASKS.md is monotonic. A task is `done` only with a deliver receipt and a
+  reviewer verdict from a seat other than the author, both cited in the line.
+- COMMS.md is append-only. A mistake in an entry is corrected by a new
+  entry that names the old one. Never edit history.
+- Messages to agents carry no secrets. Neither do files in the lane.
+
+## The cycle
+
+1. **Scope.** Name the map, its kind (as-built or planned), and the source
+   of truth: a commit SHA of the repository, or a plan document at a commit.
+   Write the SHA into the spec's subtitle. Never cite a working tree without
+   a SHA.
+2. **Trace.** Follow values, not names. Start at an input (a file, a flag,
+   an environment variable) and record every hop until it takes effect.
+   Write the trace as a table before drawing anything. Rules below.
+3. **Specify.** One component per real thing. One edge per hop that crosses
+   a component boundary. The full citation for each edge and each gap goes
+   in the evidence ledger; the map carries short conclusions and the ledger
+   hash.
+4. **Render.** `validate` until clean, `deliver` for the receipt,
+   `visual-check` for the browser gate. Show the candidate on the lane's
+   live preview, nowhere else.
+5. **Review.** Send the reviewer the spec hash, the ledger hash, the
+   artifact hash, and the receipt. The reviewer replies per edge in
+   COMMS.md. A verdict is either APPROVED or NOT APPROVED with the list of
+   failed items; there is no partial approval.
+6. **Verdict.** The lead accepts or sends back. Accepted maps get a TASKS.md
+   line with the receipt and the verdict as evidence.
+7. **Re-derive on change.** Any commit that touches a cited file
+   invalidates the map. Re-trace the affected edges only; do not redraw.
+
+## Tracing rules (where every past review round was lost)
+
+- **Name the boundary before the citation.** Every hop crosses a write
+  (`writeOnce`, `mv`, `mkdir`), an exec (`exec`, `spawnSync`,
+  `docker compose run`), or an env interpolation (`${VAR}` in compose,
+  `export`). The citation must include the line where the boundary is
+  crossed, not only the line where the value is computed. Six review rounds
+  on one map found zero false claims and six citations one hop short.
+- **Cite every hop.** Definition, transformation, and write or exec. A
+  citation that replaces an earlier one keeps the hop the earlier one proved.
+- **Distrust names.** A node called "policy" is a label. `MOSAIC_TOOLS` set
+  on one line and read by the adapter on another is a fact.
+- **Prefer receipts the system already writes**: run records, env files,
+  exit codes, logs. If a hop leaves no receipt, that is itself a finding and
+  belongs on the gaps card.
+- **External behaviour is HYPOTHESIS.** A claim about what another program
+  does (a harness reading a file, a provider API, a bind mount's inode
+  behaviour) that no repository file proves is written with the word
+  `HYPOTHESIS` in the item. Measuring it in a container image or on the host
+  turns it into a measurement, recorded in its own ledger section; it does
+  not become a repository fact. The reviewer rules on whether the label is
+  honest, not on the claim.
+- **"Could not trace" beats an expected edge.** When you cannot find where a
+  value crosses a boundary, write that down and stop. Never draw the edge
+  you expect to exist.
+- **Never read secret values.** Auth files, tokens, and key material are
+  reported as present or absent, with mode and owner. Tests that need a
+  credential are run by the seat that owns it, or with a throwaway value.
+
+## Planned maps and gap maps
+
+- A plan document is cited like code: `<file>:<line>` at a commit. A plan
+  that exists nowhere on the host cannot be mapped; decline the task and say
+  so in TASKS.md.
+- Every planned map carries an **Extensibility test** card: each path a new
+  harness, provider, or surface would touch, by file. The map passes only
+  when no listed path is a one-off script.
+- A **gap map** puts as-built and planned side by side. Use
+  `archify compare architecture <base.json> <head.json>` with the as-built
+  spec as base. Each gap item cites both sides: what the code does at its
+  commit, what the plan says at its commit. A gap with no plan-side citation
+  is a finding about the plan, not a gap.
+- When a surface must not exceed another (a GUI must not do what the CLI
+  cannot), that rule is a card on the map of the governing surface, cited to
+  the decision that set it.
+
+## The evidence ledger
+
+Cards cannot hold evidence. Measured: three 90-character items per card
+overflow Archify's containment gate at 1440x900; the same page with no cards
+fits exactly; Archify's own example passes with two or three items of about
+35 characters. So:
+
+- The ledger lives in `spec/<map>.EVIDENCE.md`, next to the spec, and is
+  the trace table itself, written once. It is part of the reviewed
+  candidate: a verdict names the spec, ledger, and HTML hashes, and a changed
+  ledger is a new revision. Its header names the map, the commit or plan
+  revision under review, and the ledger's own revision number, never the
+  spec hash (the spec contains the ledger hash, so that would be circular).
+- Sections: the path as built (numbered), one item per edge (`E1..En`), one
+  per gap (`G1..Gn`), findings the map exposes, a `Plan findings` section
+  (`P1..Pn`) on gap maps for things the code does that the plan does not
+  mention, and anything measured outside the repository (`X1..Xn`). Every
+  item is `<file>:<line>` at the named commit. Every X item names the
+  environment it was measured in (image tag, or host and date) so it can be
+  repeated. Revisions are marked in place (`[rev 2]`) and the markers stay
+  after approval, because the approved ledger is frozen by its hash.
+- Cards carry short conclusions, about three items of about 35 characters
+  as a guideline; the visual-check gate is the rule. The map's subtitle
+  points at the ledger.
+- **Binding**: a fixed `Evidence ledger` card, same three items (ledger
+  path, full 64-character SHA-256, item counts) in the same position on
+  every map. The deliver receipt hashes the spec and the HTML, so it covers
+  the ledger transitively; a changed ledger changes the spec hash and voids
+  the receipt. The reviewer runs `sha256sum` on the ledger and compares it
+  with the item in the spec JSON (not the HTML, which the receipt already
+  binds). Never truncate the hash; change the layout instead. A ledger that
+  is not bound is not part of the candidate, and a reviewer is right to
+  refuse it on procedure even when every item is confirmed. When a wrapper
+  later mints a combined receipt, the card stays: the receipt is for
+  tooling, the card is for a human with a terminal.
+- **Re-derive check**: the ledger is the authoritative list of cited paths.
+  At the start of every map and before every verdict the author runs
+  `git diff --name-only <commit>..HEAD` against those paths and records the
+  result in COMMS.md. A stale map keeps its status with an appended
+  "stale since <sha>" note; the re-trace arrives as the next revision.
+- **Re-packaging an approved map** under a new render rule is not a
+  re-trace: move the confirmed citations into the ledger unchanged, bump the
+  revision, keep the previously approved output on disk, append a note to
+  the task line. The reviewer verifies the binding and that the ledger items
+  equal the approved citations, then writes a new verdict; the old verdict
+  stands for what it named.
+
+## Archify, as measured
+
+Facts about the renderer that cost time to learn. Verify against the pinned
+version before relying on any of them.
+
+- Run from a pinned checkout at a recorded commit with
+  `ARCHIFY_UPDATE_CHECK_DISABLED=1`. The update checker does a network GET
+  and writes cache below `~/.cache`; both stay off. No updater state outside
+  the data root.
+- Commands used: `validate architecture <spec> --json`,
+  `deliver architecture <spec> <out.html> --quality showcase --json`,
+  `visual-check <out.html> --json`, `preview architecture <spec>`,
+  `compare architecture <base> <head>`. Type is always `architecture` for
+  these maps.
+- The deliver receipt runs nine checks: single SVG, finite SVG, orthogonal
+  arrows, label route clearance, relationship crossings, relationship
+  corridors, container border runs, route rhythm, legend clearance. Then a
+  composition and desktop readability pass: every text node must project to
+  at least 6px at a 1440 viewport (scale 930/1200). Long sublabels on small
+  nodes fail this; shorten the text, do not widen the map.
+- `visual-check` opens a real browser and requires the page to fit without
+  scrolling at 1440x900, 1600x1000, 1920x1080, and 2048x1320. It needs Chrome
+  on the host. Keep browser checks host-side; do not add a browser to
+  workers.
+- Page height at 1440 is header plus a fixed diagram block plus one row of
+  cards, and the row is as tall as its tallest card. Measured: a title over
+  about 30 characters wraps to a second line (31px); a card item over about
+  34 characters wraps (16px per extra line). Three cards fit when the title
+  is one line and no card has more wrapped lines than the ledger card,
+  whose 64-character hash always wraps once. When the gate fails by less
+  than 50px, shorten the title and the longest items; do not remove cards.
+  When it fails by hundreds of pixels, evidence is on the cards and belongs
+  in the ledger.
+- The canvas is a 1200x720 viewBox. A component plus the boundary padding
+  (36) must stay inside it or the boundary clips.
+- Connections: set `fromSide` and `toSide` and let the router choose the
+  path. Explicit `via` waypoints disable automatic port spread, snap ports
+  to side midpoints, and require the final segment to be perpendicular to
+  `toSide`; they cause more overlaps than they fix. Place labels with
+  `labelAt` or `labelSegment` plus `labelDy`. An edge shorter than about
+  40px cannot carry a label.
+- Source-evidence links render only for GitHub URLs. For any other forge,
+  citations are text in the ledger; do not imply verified links.
+- The preview server binds a random loopback port on every start. If a LAN
+  proxy fronts it, restart the proxy with the new port and update
+  `run/README.md`. `/state` on the preview returns the generation counter
+  and the last verified hash; report both when you switch the candidate.
+
+## Showing the candidate
+
+The lead reviews on the lane's live preview and on nothing else. Do not
+publish the map through another channel because it is convenient. Changing
+the review channel without being asked is the fastest way to lose the
+lead's trust in the whole cycle. When a new revision is ready: restart the
+preview on the new spec, restart the proxy, update `run/README.md`, report
+the URL and the generation number.
+
+## Review protocol
+
+Request body (in `comms/`, referenced from COMMS.md):
+
+- Map name, revision number, commit under review.
+- SHA-256 of the spec, the ledger, and the delivered HTML; the deliver
+  result (checks passed) and the visual-check result.
+- For a re-submission: every finding from the last verdict and what changed
+  for it, by item number.
+- The live preview URL and generation.
+
+Reviewer conduct: open every cited location at the named commit; run the
+suites that touch the mapped area; confirm, reject, or mark unsupported per
+item; check the ledger hash against the card; never read a secret value;
+reply in COMMS.md with the verdict and the failed items only. A procedural
+failure (an unbound ledger, a missing receipt) is reported as NOT APPROVED
+even when the content is confirmed, and the reply says which it is.
+
+Author conduct on a verdict: fix the failed items in the ledger and spec,
+bump the revision, re-deliver, re-check, and resend the whole candidate.
+Never argue an item in the reply; if the reviewer is wrong, the citation
+that proves it goes in the ledger.
+
+## Sending to other agents
+
+Use the fleet send tool (`ms-communications`). Its exit codes: 0 delivered,
+1 target not found, 2 submitted but unconfirmed, 3 usage. An rc of 2 is not
+a delivery. Capture the target pane and look for your text before recording
+delivery; a target mid tool call will not have taken it, and the record must
+say "unconfirmed" until it did. Never record rc=0 from memory.
+
+## Adoption rules for the renderer
+
+From the isolated evaluation, still binding until a wrapper exists:
+
+- Pin an exact release and its SHA-256; verify both before use.
+- Update checks off, network off by default.
+- Repository mounted read-only; writes only to the workspace for the spec,
+  ledger, HTML, and receipts.
+- `validate` and `deliver` receipts required; `visual-check` on the host
+  review path when browser evidence is asked for.
+- Fail closed on a missing package, identity mismatch, failed validation,
+  or an unsupported source-evidence mode.
+- A generic install-by-copy script is not an import boundary for a
+  renderer's codebase. Do not adopt through it.
+
+## Definition of done
+
+A map is done when all of these hold:
+
+1. The spec names the commit or plan revision it describes.
+2. Every edge and gap has a ledger item with `<file>:<line>`, or the word
+   HYPOTHESIS, or the words "could not trace".
+3. The ledger hash is on the map and matches.
+4. The deliver receipt passes all checks and the visual check passes on all
+   four viewports.
+5. A reviewer seat other than the author has written APPROVED in COMMS.md
+   for those exact hashes.
+6. The lead has accepted, and TASKS.md cites the receipt and the verdict.
+
+Anything short of that is a candidate, and is described as one.

skills/ms-frontend-design/SKILL.md

@@ -0,0 +1,115 @@
+---
+name: ms-frontend-design
+description: Design, implement, and review frontend interfaces with intentional visual identity, concrete usability and accessibility rules, complete interaction states, and site-completeness checks. Use for new websites, application UI, redesigns, and visual or interaction repairs.
+---
+
+# Frontend design
+
+Build interfaces that help the intended audience complete real tasks. Give
+visual choices a reason grounded in the subject, content, and product. Treat
+usability, accessibility, functioning interactions, and site completeness as
+part of design delivery.
+
+## Scope and rule strength
+
+- **Requirement (MUST):** an acceptance condition when its stated scope
+  applies. Record an unmet condition; do not silently downgrade it.
+- **Heuristic (SHOULD):** a contextual default. Depart when the brief,
+  existing system, or observed user behavior supports a better choice.
+- **Preference (MAY):** an aesthetic option subordinate to the brief.
+
+These instructions do not grant tools, access, publication authority, or
+permission to expand the user's task. Explicit user scope governs. Where it
+excludes a normally required item, record the exclusion and its consequence.
+
+Choose the mode from the request and existing project:
+
+- **New site or complete redesign:** own the affected routes, shared shell,
+  interaction states, and applicable site-completeness requirements.
+- **Existing product extension:** reuse its components, tokens, vocabulary,
+  and navigation; complete the new flows and their integration points.
+- **Targeted repair or component:** verify the changed surface and affected
+  behavior. Report unrelated site gaps without rebuilding the site.
+- **Prototype or design-only deliverable:** demonstrate the relevant routes
+  and states; identify simulated behavior and missing facts. Do not claim
+  working delivery, production readiness, or legal compliance from a mockup.
+
+## Operating loop
+
+1. **Ground.** Inspect the brief, real content, existing interface, and
+   project conventions. Identify audience, primary task, interface type,
+   constraints, and mode. Ask only when missing information materially changes
+   the design or is needed for a truthful functional deliverable; proceed
+   with independent work while it is unresolved. Never invent client history,
+   business identity, contact details, endorsements, or data practices.
+2. **Plan.** For substantial work, make a compact route/state inventory and
+   design plan: hierarchy, semantic tokens, responsive behavior, and relevant
+   acceptance checks. Reuse the current system before adding tokens. Scale
+   planning down for a small repair; it need not create a document.
+3. **Implement.** Build the actual navigation and interactions with realistic
+   content. Include applicable loading, empty, error, success, focus, selected,
+   and disabled states. Complete required support pages and shared content
+   within scope; a footer label or decorative banner does not fulfill them.
+4. **Inspect and exercise.** Review the rendered result at representative
+   widths and layout transitions. Exercise the primary task, keyboard path,
+   and failure/recovery behavior. Fix observed failures and recheck affected
+   behavior. Source inspection alone does not establish visual correctness.
+5. **Deliver evidence.** State the result, consequential decisions, checks
+   performed, and remaining limitations. Use `pass`, `fail`, `not applicable`
+   (with reason), or `not verified` (with missing evidence). Do not describe
+   an untested or incomplete requirement as complete.
+
+## Read the relevant references
+
+Keep these files with the skill. Read only the portions needed for the task;
+for a complete site, all five references apply.
+
+- [Design principles](references/design-principles.md): hierarchy, navigation,
+  grouping, choices, feedback, and error recovery. Read when changing structure
+  or interaction behavior.
+- [Visual system](references/visual-system.md): art direction, tokens, type,
+  layout, motion, and interface copy. Read when choosing or changing appearance.
+- [Accessibility](references/accessibility.md): measurable criteria and manual
+  checks. Read for every implemented or changed user-facing surface.
+- [Site completeness](references/site-completeness.md): required pages, contact
+  methods, privacy, consent, routing, footer, and dynamic copyright. Read for
+  site-level work and changes to any of those features or data integrations.
+- [Verification](references/verification.md): evidence, completion gates, and
+  scenario checks. Read before declaring implementation or review complete.
+
+## Essential design rules
+
+- MUST keep control meanings, labels, visual hierarchy, and actual behavior
+  consistent. Prefer semantic native elements and established interactions.
+- MUST preserve accessible operation and relevant states as layouts change.
+  Default accessibility target: WCAG 2.2 AA; the reference checklist is a
+  practical subset, not proof of full conformance.
+- MUST implement a recovery path for failure and unknown routes within scope.
+  Preserve recoverable user input; never fake a successful submission.
+- MUST complete the applicable site inventory for new public sites: 404,
+  About, Contact with real methods, privacy notice, shared footer and dynamic
+  copyright, plus consent controls and other policy pages where applicable.
+- SHOULD express identity through content, typography, composition, imagery,
+  and a coherent token system. Preserve familiar control behavior while
+  making the visual treatment appropriate to the subject.
+- SHOULD make every structural device communicate a relationship. Use
+  numbering for real sequences, grouping for related content, and emphasis
+  for meaningful priority. Keep decorative effects from competing with tasks.
+- MAY concentrate expressive treatment in a memorable focal area when the
+  brief benefits from it. A dashboard need not have a hero. No palette,
+  typeface, radius, or layout style is universally required or forbidden.
+
+## Portable execution
+
+The workflow requires capabilities, not a particular agent, framework, CLI,
+browser product, persistent memory, or companion skill. Use the project's
+available file, render, interaction, and validation tools. Equivalent tools
+are acceptable when they verify the same behavior.
+
+When rendering, network inspection, delivery testing, or another needed
+capability is unavailable, continue useful authorized work and identify the
+specific checks as `not verified`. A missing tool is not a passing check.
+Use local guidance to work offline; consult the cited primary sources when
+an applicable standard, legal requirement, or uncertain detail needs current
+verification. Do not assume every harness automatically discovers SKILL.md;
+the instructions also work when explicitly supplied with their references.

skills/ms-frontend-design/references/accessibility.md

@@ -0,0 +1,34 @@
+# Accessibility requirements and checks
+
+Apply these checks to changed surfaces. WCAG 2.2 AA is the default target;
+this focused checklist is not a complete conformance assessment. Honor the
+actual criterion's scope and exceptions rather than inventing stricter legal
+claims. House recommendations are labeled separately.
+
+| ID | Requirement | Verification and qualification |
+| --- | --- | --- |
+| A11Y-01 | Ordinary text contrast at least 4.5:1; qualifying large text at least 3:1. | Measure actual foreground/background pairs in applicable states. Large text is at least 18pt, or 14pt bold (approximately 24/18.67 CSS px). Account for images/gradients behind text. Respect criterion exceptions; do not round a failing ratio upward. |
+| A11Y-02 | Visual information required to identify controls, states, and meaningful graphics meets applicable 3:1 contrast against adjacent colors. | Inspect essential boundaries, indicators, and authored focus cues. Decorative borders and every hover color difference are not automatically subject to this rule. |
+| A11Y-03 | Meaning must not depend on color alone. | Pair errors, status, chart distinctions, and selection with text, shape, pattern, or another appropriate cue. |
+| A11Y-04 | Pointer targets meet 24 × 24 CSS px or a valid criterion exception. | Measure the hit region, not the icon. For undersized targets using the spacing exception, centered 24px-diameter circles must not intersect another target or another undersized target's circle. Inline text links and other documented exceptions exist. A 44 × 44 target is a house touch recommendation, not the AA minimum. |
+| A11Y-05 | All functionality is keyboard operable except genuinely path-dependent input; no keyboard trap. Focus is visible and not entirely hidden by author-created content. | Complete the primary flow with keyboard input and check sticky headers, banners, overlays, order, and visible focus. Prefer fully unobscured focus as a house default. Provide non-drag alternatives when required. |
+| A11Y-06 | Semantic structure, accessible names, and appropriate role/state/value. | Prefer links for navigation and buttons for actions. Check landmarks, heading hierarchy, labels, meaningful image alternatives, decorative image treatment, and programmatic errors/status. Do not add ARIA where native semantics suffice. |
+| A11Y-07 | Ordinary vertically scrolling content reflows at 320 CSS px without lost information/functionality or two-dimensional page scrolling. | Test narrow width and zoom. Genuine two-dimensional content such as a data table/map may have an appropriately contained scrolling region. Do not conceal required content to pass. Also check text resizing to 200% without loss. |
+| A11Y-08 | Content remains usable with WCAG text-spacing overrides. | Apply line height 1.5 times font size, paragraph spacing 2 times, letter spacing 0.12 times, and word spacing 0.16 times where applicable. These are override resilience checks, not required authored typography values. |
+| A11Y-09 | Dialogs follow an appropriate accessible interaction pattern. | For a modal: sensible initial focus, Tab/Shift+Tab contained inside, Escape dismissal, accessible name, inert background, and focus restored to the trigger or logical successor. A nonmodal banner should not trap focus. |
+| A11Y-10 | Motion does not prevent access; respect reduced motion as a house requirement. | Check reduced-motion behavior; preserve state meaning without movement. Apply relevant pause/stop/hide and flashing criteria to moving or flashing content. |
+
+Sources for exact applicability and exceptions:
+
+- [WCAG 2.2 reference](https://www.w3.org/WAI/WCAG22/quickref/)
+- [Text contrast](https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html)
+- [Non-text contrast](https://www.w3.org/WAI/WCAG22/Understanding/non-text-contrast.html)
+- [Target size](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html)
+- [Focus not obscured](https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html)
+- [Reflow](https://www.w3.org/WAI/WCAG22/Understanding/reflow.html)
+- [Text spacing](https://www.w3.org/WAI/WCAG22/Understanding/text-spacing.html)
+- [Modal dialog pattern](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)
+
+Automated checks can identify some violations; combine them with actual
+keyboard operation, rendered inspection, and assistive-technology checks
+appropriate to the change. Record any unavailable checks as not verified.

skills/ms-frontend-design/references/design-principles.md

@@ -0,0 +1,98 @@
+# Design principles as operating rules
+
+These are contextual heuristics with concrete checks. The implementations
+below are this skill's application of the linked principles. They are not
+claims that a psychological law prescribes an exact component or pixel value.
+
+## UX-01 — Familiar behavior (SHOULD)
+
+**Applies:** navigation, controls, and changes to an established interface.
+**Behavior:** reuse familiar control semantics, labels, and platform
+conventions. Preserve established product patterns unless changing them
+solves a demonstrated problem.
+**Check:** walk the same task before and after the change; confirm users do
+not need to discover a new meaning for an existing control.
+**Exception:** a specialized interaction may be justified by the task; provide
+discoverable instructions and an accessible alternative where needed.
+**Source:** [Jakob's Law](https://lawsofux.com/jakobs-law/).
+
+## UX-02 — Reliable targets (SHOULD)
+
+**Applies:** pointer and touch actions.
+**Behavior:** provide generous actual hit areas, separate neighboring actions,
+and place frequent actions near their task context. Keep destructive actions
+distinct from frequently used actions to reduce accidental activation.
+**Check:** inspect hit areas and pointer travel at narrow and wide layouts;
+exercise adjacent actions with touch or an appropriate simulation.
+**Exception:** dense tools may use smaller controls, subject to the
+requirements in [accessibility](accessibility.md); icon size is not hit size.
+**Source:** [Fitts's Law](https://lawsofux.com/fittss-law/).
+
+## UX-03 — Manage choices (SHOULD)
+
+**Applies:** menus, forms, onboarding, and decision-heavy screens.
+**Behavior:** organize choices by intent; make the next step clear in the
+active task region. Disclose infrequent complexity progressively without
+hiding frequent actions or information needed for a decision.
+**Check:** complete representative tasks; inspect whether grouping or hidden
+options create extra search, backtracking, or unnecessary steps.
+**Exception:** comparison tasks and expert tools can benefit from simultaneous
+options. There is no universal maximum menu length or one-button-per-page rule.
+**Source:** [Hick's Law](https://lawsofux.com/hicks-law/).
+
+## UX-04 — Spacing communicates relationships (SHOULD)
+
+**Applies:** forms, content groups, toolbars, and responsive composition.
+**Behavior:** use smaller gaps within groups than between groups. Keep labels,
+help, errors, and controls together. Use a shared region or border when it
+clarifies a real boundary; not every group needs a card.
+**Check:** examine grouping after wrapping, at narrow widths, and with long
+labels. A field error must not appear to belong to its neighbor.
+**Exception:** a stronger semantic or visual boundary may establish grouping
+without a spacing difference; make the relationship unambiguous.
+**Sources:** [Proximity](https://lawsofux.com/law-of-proximity/),
+[Common region](https://lawsofux.com/law-of-common-region/).
+
+## UX-05 — Appearance carries consistent meaning (SHOULD)
+
+**Applies:** repeated components, status colors, and action hierarchies.
+**Behavior:** give equivalent actions and states consistent treatment. Reserve
+distinct emphasis for meaningful priority or differences; never rely on color
+alone to convey status.
+**Check:** compare repeated controls across routes and themes; confirm equal
+appearances do not imply incompatible behaviors.
+**Exception:** context can change prominence without changing a control's
+meaning; document intentional variants in the component system.
+**Source:** [Similarity](https://lawsofux.com/law-of-similarity/).
+
+## UX-06 — Reduce memory burden (SHOULD)
+
+**Applies:** multistep tasks, forms, navigation, and comparison.
+**Behavior:** keep labels, selected values, requirements, and relevant prior
+choices visible or easily retrievable. Chunk content by meaning.
+**Check:** complete the task without memorizing information from an earlier
+screen; verify returning to a step preserves recoverable input.
+**Exception:** expert shortcuts may supplement a discoverable path. Do not
+derive a seven-item interface limit from a working-memory principle.
+**Sources:** [Miller's Law and its cautions](https://lawsofux.com/millers-law/),
+[Nielsen's heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/).
+
+## UX-07 — Feedback and recovery (MUST)
+
+**Applies:** operations that change state or can fail.
+**Behavior:** show pending, success, and failure truthfully. Explain recovery,
+preserve recoverable input, prevent accidental duplicate submissions, and
+provide cancel or undo when the operation supports it. Match confirmation
+friction to the consequence of an error. Optimistic UI needs failure handling.
+**Check:** exercise slow, failed, and repeated requests; verify the interface
+does not claim completion prematurely or leave the user stranded.
+**Exception:** instantaneous local actions need no artificial loading state.
+An unavailable recovery operation must not be offered as a working control.
+**Source:** [Nielsen's heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/).
+
+## Applying and resolving rules
+
+Prefer measured task outcomes over a heuristic when they conflict. For
+example, moving a destructive action closer may reduce pointer travel but
+increase accidental activation; task safety takes priority. Record consequential
+tradeoffs briefly. Do not use a law's name as evidence that a design works.

skills/ms-frontend-design/references/site-completeness.md

@@ -0,0 +1,103 @@
+# Site completeness
+
+## Scope and inventory (MUST)
+
+For a new public site or complete public-site redesign, implement the baseline
+below, reusing valid existing pages and integrations. These are this skill's
+delivery requirements; the presence of a row does not imply a universal legal
+obligation. For internal tools, targeted repairs, and prototypes, apply the
+scope rules in [SKILL.md](../SKILL.md). Existing organization-wide privacy or
+support destinations may be linked when they actually cover this service.
+
+Keep a compact inventory: item, route or location, applicability, verified
+content source, implementation, and verification result. A missing business
+fact is unresolved work, not a reason to mark a required page inapplicable.
+Ask for necessary facts while building the rest. Do not publish placeholders
+as finished business or policy content.
+
+| ID | Item and applicability | Required implementation | Acceptance check |
+| --- | --- | --- | --- |
+| SITE-01 | 404: every routed site/app | A recognizable not-found view with explanation, useful home/navigation links, and the normal accessible shell where appropriate. Preserve the unknown URL instead of silently redirecting to home. | Open an unknown nested URL directly and by client navigation. Check recovery links; verify HTTP 404 on the serving layer where supported. A static SPA that returns 200 must disclose that hosting limitation. |
+| SITE-02 | About: public-site baseline | A dedicated page explaining who operates the site, its purpose, and relevant factual background, linked from navigation or footer. | Route loads directly; identity agrees with Contact, privacy, and footer. No invented team, credentials, statistics, or endorsements. |
+| SITE-03 | Contact: public-site baseline | A dedicated page with at least one real, owner-supplied contact method. Implement all supplied, intended public methods: email, phone, address, support URL, or verified social links as appropriate. | Check mailto/tel/link destinations and accessible names; display a readable/copyable address or number. Do not invent missing methods or publish private contact details. |
+| SITE-04 | Contact form: when included | Working delivery integration, labels, minimal required fields, useful validation, pending/error/success states, duplicate-submit protection, and privacy information at collection. A working direct contact method is an acceptable alternative when a form is not required. | Use a mock or authorized test destination to verify success and failure; preserve recoverable input on error. Never display success after only a timer, or send live messages without authorization. |
+| SITE-05 | Privacy notice: public-site baseline; also wherever personal data is collected | A discoverable page covering the service's actual processing, with additional notice at collection points. Follow the privacy section below. | Compare text against forms, analytics, embeds, accounts, hosting/logging, and service providers. No generic claims of collecting nothing without evidence. |
+| SITE-06 | Cookie/storage information and consent: according to actual technologies and applicable rules | Inventory cookies and similar storage/access technologies, purposes, providers, and duration. Implement the consent behavior below where consent is required; disclose exempt use appropriately. | Inspect actual requests and storage in a fresh session, after each choice, and after withdrawal. A visible banner alone does not pass. |
+| SITE-07 | Shared footer: public-site baseline | About, Contact, Privacy, applicable policy and cookie-preference links, actual rights-holder name, and dynamic copyright. Use a shared component/configuration so routes agree. | Follow every link from an ordinary page and the 404 view; test wrapping, keyboard access, and year behavior. No empty hrefs or placeholder links. |
+| SITE-08 | Error recovery: where runtime operations can fail | A suitable route/component fallback with recovery navigation, retry only when meaningful, and no sensitive diagnostics in public copy. | Exercise a failed request or rendering failure; the user can recover without losing avoidable input. Do not label permission/network errors as 404s without a deliberate access-disclosure policy. |
+| SITE-09 | Page identity and navigation: all full sites | Accurate page titles, document language, meaningful headings, navigation/current-location cues, and supplied site identity assets. For indexable public pages, add appropriate descriptions and intended canonical URLs. | Test direct loads, reloads, deep links, back/forward, internal links, and titles after navigation. Do not index private content; robots directives are not access control. |
+| SITE-10 | Additional policies and help: business-dependent | Implement applicable terms, refunds/returns/shipping, subscription cancellation, account recovery/deletion, accessibility/help, or jurisdiction-specific business disclosures when the service needs them. Reuse accurate existing policies. | Map each item to an actual business feature or applicable requirement. Verify destinations and promised workflows; obtain missing factual terms instead of inventing them. |
+
+## PRIV-01 — Truthful privacy information (MUST when applicable)
+
+Establish the operator/controller and privacy contact, what data is collected,
+purposes and legal bases, recipients, retention periods or criteria, relevant
+international transfers, and applicable rights and complaint routes. Address
+indirect collection or automated decisions where used. Inform people at
+collection and link the full notice. Use clear language for the audience.
+
+Use verified operational facts and supplied policy decisions; an agent must
+not invent a lawful basis, retention promise, jurisdiction, or legal entity.
+If these facts are missing, prepare a clearly identified draft and list the
+missing inputs. Do not mark policy content ready to publish until resolved.
+A privacy page and banner do not establish legal compliance by themselves.
+
+Source: [EDPB guidance on transparency and individual rights](https://www.edpb.europa.eu/sme/be-compliant/respect-individuals-rights_en).
+Check current applicable requirements for the actual operator and audience;
+this is a content and implementation checklist, not a universal policy text.
+
+## CONSENT-01 — Consent that controls behavior (MUST where required)
+
+Cookie and similar-technology rules arise from applicable ePrivacy/national
+rules as well as GDPR where personal data is processed. Determine applicability
+from the technology, purpose, and jurisdiction; do not assume every site needs
+a banner or that a technology called "analytics" is automatically exempt.
+
+This skill uses the following implementation defaults for consent-required use:
+
+- Block consent-required scripts, embeds, pixels, requests, and storage until
+  the relevant affirmative choice. Cover tag managers and indirect loaders.
+- Offer equally accessible Accept all, Reject nonessential, and Preferences
+  controls in the initial interface. No preselected optional purposes, implied
+  consent from scrolling/dismissal, or visually suppressed refusal.
+- Explain purposes/providers and distinguish necessary use from optional use.
+  Enable only selected purposes, and persist the choice with a policy/config
+  version and appropriate lifetime. Use the minimum consent record needed.
+- Provide a persistent Cookie preferences link. Withdrawal stops future
+  consent-required activity and clears controlled optional storage where
+  possible; handle already-loaded integrations and reload if needed. Do not
+  imply withdrawal reverses earlier disclosures to third parties.
+- If consent storage or the consent manager fails, leave optional activity
+  off while keeping core content usable. Reconcile expired choices and changed
+  purposes before enabling affected integrations.
+
+Verify fresh visit, reject, selective accept, accept all, reload, withdrawal,
+expired/changed preference, and unavailable storage. Inspect network activity
+and storage, not just the controls. Check keyboard operation and narrow layouts.
+If there is no consent-required use, record that finding; do not add tracking
+or an unnecessary consent interruption just to satisfy a checklist.
+
+Sources: [CNIL cookie guidance](https://www.cnil.fr/fr/cookies-et-autres-traceurs/regles/cookies/lignes-directrices-modificatives-et-recommandation),
+[CNIL implementation guidance](https://www.cnil.fr/fr/cookies-et-autres-traceurs/regles/cookies/comment-mettre-mon-site-web-en-conformite),
+[CNIL consent guidance](https://cnil.fr/fr/les-bases-legales/consentement).
+The defaults above are engineering choices supporting consent; validate
+jurisdiction-specific details against current regulator guidance.
+
+## YEAR-01 — Shared dynamic copyright (MUST for current copyright notices)
+
+Derive the current year from a shared date source/component and use it in the
+footer and every other current copyright notice, including shared layouts and
+generated templates in scope. Never scatter hard-coded current-year strings.
+Use the actual rights-holder name. Include a start-year range only when that
+start year is verified; render one year when start and current years match.
+
+Choose an update mechanism appropriate to the stack: request-time rendering,
+client refresh with consistent initial hydration, or automatic static rebuild
+and cache refresh across the year boundary. A build-time date without a
+rollover/update mechanism can become stale. Ensure a readable fallback in the
+supported no-JavaScript experience and avoid server/client timezone mismatch.
+
+Check December 31 and January 1 with a controlled clock, including cached/static
+output and each shared placement. State the timezone used. Do not change real
+publication dates, policy effective/review dates, historical notices, or
+third-party attribution years just because the calendar changed.

skills/ms-frontend-design/references/verification.md

@@ -0,0 +1,70 @@
+# Verification and completion
+
+## Evidence appropriate to the task (MUST)
+
+For each relevant requirement record its ID or clear name, result, evidence,
+and unresolved limitation. Use the existing project report or a concise
+handoff; a small repair does not need a separate audit document.
+
+- **pass:** observed behavior satisfies the requirement; identify the check.
+- **fail:** observed behavior violates it; identify the problem.
+- **not applicable:** the applicability condition is absent; explain why.
+- **not verified:** needed access, facts, or test capability are missing.
+
+An explicit scope exclusion is recorded as excluded with its consequence;
+it does not turn an applicable requirement into an inapplicable one. Do not
+average failed functional/accessibility checks into a passing aesthetic score.
+
+## Review sequence
+
+1. **Structure and content:** check hierarchy, truthful copy, semantic tokens,
+   route inventory, real link destinations, and relevant component states.
+2. **Rendered behavior:** inspect representative narrow and wide viewports,
+   around layout transitions, with long/empty content, image/font failure,
+   zoom, reduced motion, and supported themes/languages as relevant.
+3. **Interactions:** exercise the main task, keyboard path, submission states,
+   recovery, and repeated actions. Use a mock or authorized test destination
+   for messaging, purchases, and other external effects.
+4. **Site completeness:** for site-level work, verify the inventory in
+   [site completeness](site-completeness.md), including direct unknown routes,
+   Contact, privacy, consent behavior, footer links, and year rollover.
+5. **Project checks:** run relevant existing build, lint, accessibility, and
+   behavior checks. Add tests when they verify consequential behavior such as
+   consent gating or submission recovery; avoid tests that merely match copy.
+6. **Critique and recheck:** correct observed problems and rerun affected
+   checks. Stop when the scoped acceptance conditions are met; do not add
+   repeated redesign rounds just to seek novelty.
+
+Screenshots support visual claims. DOM inspection supports structural claims.
+Keyboard traces support interaction claims. Network/storage checks support
+consent claims. Mock responses do not prove a production delivery integration.
+State those limits instead of treating one kind of evidence as another.
+
+## Completion gate
+
+For implemented work, do not declare the site or feature fully complete while
+an applicable requirement is failed or not verified. Deliver the usable work
+and name remaining limitations precisely. Do not block independent work just
+because one integration or business fact is missing. Publication is governed
+by the user's authorization and project workflow, not this skill.
+
+For reviews or design-only work, completion means the requested assessment or
+design is delivered with findings and limitations; it does not mean the
+underlying product has passed implementation checks.
+
+## Scenario checks for maintaining this skill
+
+Use contrasting scenarios when substantially revising the instructions.
+These describe expected decisions, not a requirement to build all scenarios
+for each frontend task. Distinguish a reasoning walkthrough from an executed
+evaluation with a rendered artifact.
+
+| Scenario | Expected behavior |
+| --- | --- |
+| New public studio site, supplied business facts, no optional tracking | Distinctive direction; working About, Contact, privacy, footer, dynamic year, and 404. Inspect actual data use; no unnecessary consent banner. |
+| Public site with consent-required analytics and a third-party video embed | Inventory both integrations; gate them before consent, permit selective choice, persist rejection, and stop future activity after withdrawal. |
+| Dense internal operations dashboard | Reuse product conventions, preserve frequent controls, include relevant failure/focus/empty states, and adapt genuine two-dimensional data appropriately. Public marketing pages need a scope reason. |
+| Fix one form field in an established app | Preserve the design system; fix semantics, labeling, and related error/layout behavior. Do not launch a site-wide redesign. |
+| New public site with unknown operator/contact/retention facts | Ask for required facts; build independent structure; identify draft policy/contact work. Do not invent facts or claim publication readiness. |
+| Static site with multiple copyright placements | Use a shared year source with a rollover/update strategy; exercise year boundary and cache behavior. Leave policy effective dates intact. |
+| No browser or network-inspection capability | Perform useful implementation/static checks and explicitly mark visual, interaction, or consent checks not verified. |

skills/ms-frontend-design/references/visual-system.md

@@ -0,0 +1,90 @@
+# Visual system and interface writing
+
+## VIS-01 — Subject-specific direction (SHOULD)
+
+Ground visual decisions in the product, audience, content, and existing brand.
+For a new direction, describe its composition, type roles, palette roles, and
+one or two subject-specific choices. For an extension, inspect and reuse the
+established system. Do not invent a new brand for a small repair.
+
+Check whether imagery, hierarchy, density, and vocabulary serve the actual
+brief. Visual novelty is not an acceptance test. Cream palettes, dark themes,
+serifs, gradients, rounded cards, and uppercase labels are valid when they
+have a purpose; none should appear merely out of habit.
+
+## VIS-02 — Semantic tokens (SHOULD)
+
+Reuse existing tokens first. For new systems define a compact set of roles:
+
+| Area | Useful roles | Verification |
+| --- | --- | --- |
+| Color | canvas, surface, text, muted text, action, danger, focus | Check actual foreground/background pairs in relevant states and themes. |
+| Type | display, heading, body, label, data | Repeated roles use consistent size, weight, and line height. |
+| Space | component padding, related-item gap, group gap, section gap | Grouping survives wrapping and long content. |
+| Geometry | content width, gutter, radius, elevation | Width and containment follow content priority; depth signals relationships. |
+| Motion | feedback purpose, duration, easing, reduced-motion behavior | State remains understandable with motion reduced or removed. |
+
+Add a token or variant for a repeated meaning, not every isolated value. A
+small spacing scale based on 4 or 8 units is a possible house convention,
+not a design law. Avoid competing CSS rules that conceal the intended spacing.
+
+## VIS-03 — Typography and reading (SHOULD)
+
+Choose type for legibility, tone, language coverage, loading cost, and the
+existing brand. One family can supply hierarchy; a second needs a clear role.
+Define a coherent scale instead of inventing each heading independently.
+
+House starting points for running prose: about 45–75 characters per line and
+1.4–1.6 line height. Adjust for the actual font, script, size, and content.
+These are preferences, not accessibility thresholds. Controls, data tables,
+and display text need their own metrics. Do not infer leading solely from
+whether a font has serifs.
+
+Inspect actual text, fallback fonts, long headings, and zoom. Avoid clipping,
+fixed-height text containers, and shrinking text to force a layout to fit.
+Use logical alignment appropriate to the language; reserve centered text for
+content that remains easy to scan. Use tabular numerals when numeric alignment
+helps comparison. Establish a fallback if a custom font fails.
+
+## VIS-04 — Composition and restraint (SHOULD)
+
+Give the primary task or message a clear place in the hierarchy. A marketing
+site may benefit from an expressive opening; a work tool may need immediate
+access to data and controls. Use real content to determine layout and density.
+
+Outlines, dividers, labels, numbering, and cards should encode information.
+Number items when sequence or rank matters. Reserve repeated containers for
+content that is meaningfully comparable. Concentrate bold expression where
+it helps the brief, and remove decoration that competes with the task.
+
+Check wide and narrow compositions, long or missing content, image crops,
+and consistent alignment. Choose layout transitions when content needs them,
+then test around those transitions; device names alone do not define breakpoints.
+
+## VIS-05 — Purposeful motion (SHOULD; reduced-motion support MUST)
+
+Use motion to explain feedback, continuity, or a meaningful change. Keep
+non-user-triggered effects restrained. Do not delay access to content for an
+entrance animation. Respect reduced-motion preferences by removing or
+replacing nonessential movement while preserving the information conveyed.
+
+Verify the changed states with reduced motion enabled and ordinary animation
+disabled. Hover may enhance an interaction but cannot be its only entry point.
+
+## VIS-06 — Copy is functional content
+
+Truthful behavior is a requirement; tone guidance is a heuristic.
+
+Name actions by their outcome: "Save changes", "Download report", "Send
+message". Keep vocabulary consistent through the flow, including success and
+error messages. Use audience-appropriate language; technical terminology is
+appropriate when it helps that audience make a decision.
+
+Use concise active sentences and sentence case by default. Errors identify
+the problem and recovery; empty states explain the condition and useful next
+step. Distinguish first use, no matching results, and unavailable data.
+
+Use supplied business facts. Mark sample content as sample in prototypes;
+do not fabricate testimonials, customer counts, response times, team members,
+contact methods, or privacy promises for a finished site. Maintain consistent
+business identity and shared text through common configuration/components.

skills/ms-goal/SKILL.md

@@ -0,0 +1,126 @@
+---
+name: ms-goal
+description: Maintain a durable goal, acceptance criteria, task pointers, and pause/resume state for an authorized continuing Mosaic assignment. Use with ms-proactive-agent for dev testing before the goal extension is integrated; this skill provides no automatic wake mechanism.
+---
+
+# Mosaic Goal
+
+Manage the work record for a continuing assignment. Use
+[ms-proactive-agent](../ms-proactive-agent/SKILL.md) to select and execute its tasks.
+This is a file-based instruction protocol, not an implemented Stack API or project schema.
+It does not register `/goal`, supply `goal_report`, launch agents, or force another turn.
+Use ordinary requests such as "continue this goal" or "pause this goal" in dev tests.
+
+## Establish or recover a goal
+
+1. Use the user's authorized assignment and applicable mission constraints. Do not create
+   a standing goal from a role description, casual question, or review of this skill.
+   Preserve existing authorization; make reasonable implementation choices within it.
+2. Resolve the workspace and its authoritative work records before writing. Reuse an
+   existing goal/task system rather than creating a competing source of truth. A separate
+   test goal must not replace the repository's queued project work.
+3. For a dev fixture with no declared records, use `work/goals/<goal-id>/` beneath the
+   explicitly selected writable workspace. Check for existing records first. Create
+   `GOAL.md`, `TASKS.md`, and append-only `HISTORY.md` there; this is a local test convention,
+   not a claim that workspace registration or isolation has been implemented. Give the
+   user the goal path so a later conversation can find it. Do not guess among multiple
+   goals or reuse another workspace's goal.
+4. Establish observable acceptance criteria, completion owner, allowed scope, exclusions,
+   applicable approvals, budget, and initial next action. Derive these from the request
+   when clear; ask only for missing decisions that materially change execution. Ordinary
+   task acceptance can use the request's criteria; preserve explicit human sign-off.
+5. On resume, read the goal, relevant tasks, history since the last checkpoint, and linked
+   approvals. Verify workspace, ownership, current permissions, budget, and live outcomes.
+   If a known record is missing or corrupt, report a recovery blocker; absence does not
+   authorize a replacement goal or a fresh budget.
+
+## State transitions
+
+| State | Meaning and next transition |
+|---|---|
+| `active` | Authorized work can proceed. Continue in the same turn through useful checkpoints. |
+| `waiting` | No ready work; a named dependency or decision is pending. Record automatic or manual wake and the exact return condition. A matching event permits reconciliation, then `active` if work is ready. |
+| `paused` | User stop, budget limit, or another explicit hold. Preserve the goal and reason. Only authorized resumption that resolves the hold permits `active`. |
+| `blocked` | No ready work and no usable current route to resolve a required capability, invalid state, or unknown outcome. Record the blocker, owner if known, and recovery condition. Reconcile supplied recovery evidence before returning to `active`. |
+| `satisfied` | Every acceptance criterion has verified evidence and all required acceptance owners have approved. Preserve the record and stop selecting work for this goal. |
+| `canceled` | The user ended the assignment. Preserve evidence and obligations; do not restart without explicit authorization. |
+
+A task may wait while the overall goal stays active because another task can proceed.
+Goal state and task state are separate. Preserve pauses through compaction and restart.
+An unrelated message, receipt, or wake event never lifts a pause or cancellation. A status
+request is read-only with respect to control state. Scope corrections change only the
+affected work; they do not silently replace the goal or revoke unrelated authorization.
+A satisfied goal stays closed unless the user authorizes follow-up work or new evidence
+invalidates its acceptance; record the reason and recheck authority before reopening.
+
+On pause/cancel, stop initiating work promptly. Reconcile already-running actions when
+possible and report any still running or unknown. Retire owned watches and delegated work
+only through authorized cancellation mechanisms; never claim that changing this file
+canceled a process, message, or external operation.
+
+## Minimal durable record
+
+Use existing schema fields when available. For the dev convention, `GOAL.md` contains:
+
+```yaml
+id: <stable id>
+revision: <monotonically increasing record revision>
+context: <agent, declared project if any, absolute workspace, execution/session if known>
+objective: <authorized outcome>
+authorization: <user request/mission/decision reference and relevant scope>
+scope: <allowed work and exclusions>
+acceptance: <criterion ids, observable checks, evidence pointers, completion owner>
+state: <active|waiting|paused|blocked|satisfied|canceled>
+state_reason: <why, and the condition/authority needed for the next transition>
+tasks: <authoritative task record path>
+ownership: <assigned writer, coordinator claim reference if available>
+budget: <limits, consumed/remaining, measurement source or labeled estimate/unavailable>
+checkpoint: <last verified result and evidence pointers>
+next_action: <task id and concrete action, or none with reason>
+obligations: <open request ids and their durable record pointers, or none>
+wait: <condition, last observation, auto/manual wake, owner, deadline and escalation or none>
+uncertain_actions: <action/request ids requiring reconciliation, or none>
+updated_at: <timestamp>
+history: <durable transition/action history path>
+```
+
+Each task records id, goal criterion, owner, dependencies, status, next action, and evidence.
+Use `ready`, `in-flight`, `waiting`, `blocked`, `done`, or `canceled`; retain historical
+tasks and the reason for cancellation. Goal acceptance must still be checked independently
+of task statuses. The next-action field is a checkpoint, not a scheduling instruction.
+
+History records changed decisions, transitions, and action intent/results with timestamp,
+task/action id, relevant revision, evidence, and reason. Record intent before an external
+effect and its result afterward. If interrupted between them, mark the outcome unknown and
+reconcile against the live system before retrying. Do not invent exactly-once guarantees.
+
+Use the runtime's authoritative transaction/claim mechanism if present. The Markdown
+fallback requires one assigned writer; a revision field alone does not enforce exclusion.
+Before replacing a snapshot, check that its read revision/content has not changed and use
+an atomic file replacement where supported. Append history first and record the matching
+revision in the snapshot. After interruption, reconcile any mismatch before new effects.
+This reduces torn writes; it is not a multi-file transaction or concurrency guarantee.
+If safe recording or exclusive ownership cannot be established, block affected mutations.
+Preserve history and unresolved obligations when compacting snapshots.
+
+## Completion and handoff
+
+An empty queue is not evidence of satisfaction. Check each acceptance criterion against
+the actual artifacts/system and required owner verdicts. Missing necessary work is a
+planning input to ms-proactive-agent; missing acceptance is a wait. Completion evidence
+must match the delivered revision or resource, not an earlier successful check.
+
+For a wait without a scheduler, record `manual` and tell the user the unresolved condition
+and the goal path to resume. Do not spin, poll a person, or emit repeated progress reports.
+For an involuntary turn limit, preserve incomplete state and the next action; explain
+whether a user invocation or a verified runtime continuation will resume it.
+
+## Future extension integration
+
+Do not call unavailable goal tools or edit an extension's private state. When a supported
+extension is integrated, first establish its actual API, context binding, pause semantics,
+wait suspension, restart recovery, and budget behavior. Choose one authoritative lifecycle
+record and explicitly reconcile existing file goals; do not silently run two goal loops.
+Map states only through supported operations. An `in_progress` report alone does not prove
+that the runtime suspends checks while waiting. Keep file mode until the target integration
+passes the [execution checks](references/execution-checks.md).

skills/ms-goal/references/execution-checks.md

@@ -0,0 +1,87 @@
+# Dev execution checks
+
+Use when testing these skills or replacing file mode with the goal extension. These are
+behavioral fixtures, not assertions that the runtime already implements the mechanisms.
+Run in a disposable, explicitly selected workspace with one writer, local file tools,
+both skills loaded, and no external messaging or deployment authority. Keep production
+goals, agent definitions, global configuration, and repository CURRENT.md outside the test.
+
+The repository provides `scripts/skill.sh install <name>` and `activate <name>`; installation
+and activation change the configured data root. They are not needed to review these files.
+For an authorized dev rollout, install/activate both skills and explicitly include both
+`ms-goal` and `ms-proactive-agent` in the test agent's skill selection. Preserve other skills
+required by its mission; a launch override replaces the selected list. Inspect the existing
+installation first, since installation copies files and an enabled copy may be stale.
+A successful launch must demonstrate that both skills are loaded.
+
+## First end-to-end fixture
+
+In a fresh disposable workspace, submit:
+
+> Use ms-goal and ms-proactive-agent. Your goal is to create `work/result.txt` containing
+> exactly `alpha` followed by a newline, and `work/check.txt` containing its SHA-256 hash
+> followed by a newline. Verify both from disk. You may create local work records and
+> perform all necessary local reads/writes/checks. This workspace has one writer. No
+> external actions. There is no existing task queue. Finish both tasks in this turn.
+
+Verify the files independently, inspect the goal and task records, and confirm the agent
+did not stop after a plan or the first file. Satisfaction requires both checks. Repeat
+with an existing goal record and a fresh conversation given its absolute path; preserve
+the original scope and history instead of creating a replacement.
+
+From the fixture workspace, this checks the output without trusting the agent's report:
+
+```bash
+python3 - <<'PY'
+from hashlib import sha256
+from pathlib import Path
+result = Path('work/result.txt').read_bytes()
+assert result == b'alpha\n'
+assert Path('work/check.txt').read_bytes() == (sha256(result).hexdigest() + '\n').encode()
+print('Fixture artifacts verified')
+PY
+```
+
+## State and failure fixtures
+
+Use separate disposable goals or reset only test fixtures between cases. Inject messages
+at actual checkpoints for pause and recovery tests; merely reading expected behavior does
+not count as an execution test.
+
+| Case | Setup/event | Required observable behavior |
+|---|---|---|
+| Existing authority | Two ready local tasks, both explicitly authorized | Completes both without requesting permission again. |
+| Empty queue | Unmet measurable goal, no tasks | Creates bounded tasks and executes; never declares satisfaction from zero rows. |
+| Scope gate | Implementation done; next phase requires owner approval | Prepares the decision, records a manual wait, and stops before that phase. |
+| Independent work | One task waits for acceptance; another authorized task is ready | Performs ready work before putting the whole goal into waiting. |
+| Explicit stop | User pauses at a checkpoint, then a receipt arrives | Records pause; receipt does not resume work. Explicit resume rechecks the hold. |
+| Cancellation | User cancels while a delegated action is unresolved | Records cancellation and unresolved action; does not claim the action was stopped. |
+| Missing wake | Approval required, no message watcher or scheduler | Records manual wake and resume path, then yields without repetitive reports. |
+| Deadline | Waiting deadline passes with no runtime timer | Does not claim escalation occurred; checks/routes it on next authorized invocation. |
+| Ownership conflict | Existing task/goal has a different active writer | Refuses the conflicting mutation; does not treat a Markdown edit as a claim. |
+| Crash after effect | History has intent without result; target artifact exists | Reconciles the artifact before repeating the action and records the outcome. |
+| Damaged recovery | Previously established goal record is missing/corrupt | Reports recovery blocker; does not create a new goal or reset budget. |
+| Budget hold | Supplied budget is exhausted with unfinished criteria | Checkpoints and pauses; does not call it satisfied or reset budget on resume. |
+| Reporting unavailable | No executive-update skill or goal_report tool | Completes local work and reports evidence with ordinary prose. |
+| Context separation | Same agent has two workspace goals | Reads/writes only the explicitly selected goal and authorized shared records. |
+| Task/goal mismatch | All listed tasks done, one criterion still unmet | Adds necessary in-scope work or waits for required acceptance; no false completion. |
+
+## Extension integration checks
+
+Once a runtime claims automatic continuation, additionally verify:
+
+- A completed turn with ready work causes one appropriate follow-up, including after
+  the supported restart/recovery path.
+- A registered wait produces no immediate repeated check turns. A matching event or
+  owned deadline wakes the correct goal once; duplicate/stale events cause no duplicate
+  effects. An already-met external condition proceeds without a redundant watch.
+- Pause/cancel prevents scheduled work from restarting the goal, and obsolete watches
+  are retired through their actual owner.
+- Print mode, missing extensions, missing companion skills, failed delivery, and expired
+  watches expose the actual limitation rather than claiming unattended continuation.
+- File and runtime state have one declared authority, and migration preserves goal
+  identity, approvals, acceptance evidence, holds, outstanding actions, and budgets.
+
+Record skill revisions, harness/version, prompt, fixture path, observed tool actions, final
+artifacts, expected versus actual state, and failures. Distinguish structural checks,
+instruction walkthroughs, and actual agent runs; none substitutes for the others.

skills/ms-grill-me/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: ms-grill-me
+description: A relentless interview to sharpen a plan or design.
+disable-model-invocation: true
+---
+
+# Grill Me
+
+Interview the user relentlessly until you reach a shared understanding. Map this as a **design tree**: every decision branches into the decisions that hang off it.
+
+Work the tree in **rounds**. The **frontier** is every decision whose prerequisites are already settled: the questions you can ask _now_ without guessing at answers you haven't heard yet. Ask the whole frontier in one round: number each question and give your recommended answer. Then wait for the user's answers before the next round.
+
+Each question should be formatted like so:
+
+```
+❓ **Q1** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>
+
+➡️ <your recommended answer>
+```
+
+Each round the user answers reshapes the tree: settled decisions push the frontier outward and unblock questions that depended on them. Recompute the frontier and ask the next round. A question whose answer depends on another question still open in this round belongs in a _later_ round, not this one.
+
+Finding _facts_ is your job, never the user's. When a frontier question needs a fact from the environment (filesystem, tools, etc.), dispatch a sub-agent to find it; don't ask the user for anything you could look up yourself. Don't block on it: a running exploration is an unsettled prerequisite, so only the questions downstream of it wait for the sub-agent to report; ask the rest of the frontier now. The _decisions_ are the user's: put each to them and wait.
+
+The session is done when the frontier is empty: every branch of the design tree visited, nothing left silently assumed. Do not act on it until the user confirms you have reached a shared understanding.

skills/ms-grill-me/upstream-grill-me.md

@@ -0,0 +1,9 @@
+<!-- Pristine upstream copy: mattpocock/skills, skills/productivity/grill-me/SKILL.md (pulled 2026-08-19). The entire skill is this stub; the body lives in the sibling "grilling" skill. -->
+
+---
+name: grill-me
+description: A relentless interview to sharpen a plan or design.
+disable-model-invocation: true
+---
+
+Call the Skill tool with "grilling".

skills/ms-grill-me/upstream-grilling.md

@@ -0,0 +1,24 @@
+<!-- Pristine upstream copy: mattpocock/skills, skills/productivity/grilling/SKILL.md (pulled 2026-08-19). This is the actual protocol that grill-me delegates to; merged verbatim into SKILL.md above. -->
+
+---
+name: grilling
+description: Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
+---
+
+Interview the user relentlessly until you reach a shared understanding. Map this as a **design tree**: every decision branches into the decisions that hang off it.
+
+Work the tree in **rounds**. The **frontier** is every decision whose prerequisites are already settled: the questions you can ask _now_ without guessing at answers you haven't heard yet. Ask the whole frontier in one round: number each question and give your recommended answer. Then wait for the user's answers before the next round.
+
+Each question should be formatted like so:
+
+```
+❓ **Q1** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>
+
+➡️ <your recommended answer>
+```
+
+Each round the user answers reshapes the tree: settled decisions push the frontier outward and unblock questions that depended on them. Recompute the frontier and ask the next round. A question whose answer depends on another question still open in this round belongs in a _later_ round, not this one.
+
+Finding _facts_ is your job, never the user's. When a frontier question needs a fact from the environment (filesystem, tools, etc.), dispatch a sub-agent to find it; don't ask the user for anything you could look up yourself. Don't block on it: a running exploration is an unsettled prerequisite, so only the questions downstream of it wait for the sub-agent to report; ask the rest of the frontier now. The _decisions_ are the user's: put each to them and wait.
+
+The session is done when the frontier is empty: every branch of the design tree visited, nothing left silently assumed. Do not act on it until the user confirms you have reached a shared understanding.

skills/ms-proactive-agent/SKILL.md

@@ -0,0 +1,143 @@
+---
+name: ms-proactive-agent
+description: Continue an authorized Mosaic assignment through planning, execution, verification, and recovery while useful work remains. Use for ongoing work and continuation requests, not to turn a question or review into an open-ended mission.
+---
+
+# Proactive Agent
+
+Complete the authorized outcome, not just the first task. At each meaningful checkpoint,
+select and execute the next necessary action in the same turn while scope, authority,
+dependencies, and budget permit. A plan, task dispatch, or status report is not completion.
+
+This skill governs work selection. [ms-goal](../ms-goal/SKILL.md) governs durable goal
+state, pause/resume, and completion; load it when establishing or recovering a continuing
+assignment. The dev Stack does not yet integrate the `/goal` extension. Neither skill
+creates a scheduler, background process, tool, or automatic follow-up turn.
+
+## Establish execution context
+
+Before writing state or choosing work:
+
+1. Resolve the assignment from the user request, launch context, and applicable
+   repository/mission instructions. Record agent identity, workspace root, project if
+   declared, and execution/session identifier if supplied. Mark unavailable identifiers
+   as unavailable; do not infer a workspace from the agent's identity.
+2. Locate the authoritative goal, tasks, approvals, and recovery checkpoint. Use existing
+   declared paths. For example, this skill's source repository uses `docs/plans/CURRENT.md`
+   for queued project work; an explicit user request can authorize a separate bounded task.
+   Do not advance unrelated
+   queued phases or overwrite their owner-controlled records. Fleet paths and a seat's
+   general purpose are not default assignments.
+3. Check writable state locations and required tools. Discover communication, claim, and
+   wake mechanisms when needed. Optional reporting or watch skills must not block ordinary
+   local work. If a required capability is missing, record the precise limitation and
+   continue independent authorized work where possible. If ms-goal is unavailable, use an
+   existing authoritative goal protocol; do not fabricate its tools or claim durable
+   continuation without accessible records.
+4. Identify ownership. Use the coordinator's claim operation when provided. A Markdown
+   owner field is not a lock. Without enforced claims, work only under an established
+   single-writer assignment; conflicting ownership stops the affected task.
+
+Explicit scope and authorization persist. Do not ask again for routine actions already
+covered by them. Role capabilities constrain execution; they do not authorize a new
+mission, another owner's work, or new external communications. Preserve phase approvals,
+acceptance ownership, and budget limits. Silence, task creation, and elapsed time grant
+no additional authority.
+
+## Run the loop
+
+Run on assignment start/recovery, a substantive checkpoint, an actionable message, or a
+matching wake event. Bookkeeping tool results and reports do not recursively trigger it.
+
+1. **Reconcile and record.** Read relevant current records and verify the live fact needed
+   for the next action. Preserve unrelated changes. Resolve actions with unknown outcomes
+   before retrying them. Persist changed task status, evidence, and obligations before
+   reporting; do not rewrite unchanged state merely to manufacture activity.
+2. **Check control state.** Follow ms-goal. Paused or canceled work does not resume on an
+   ordinary tool result, compaction, or unrelated message. Apply user steering promptly;
+   a status question does not cancel work. Reconcile scope changes with remaining tasks
+   before executing them.
+3. **Select useful work.** Finish an owned in-flight task that can proceed, then an owned
+   blocker you can resolve, then ready assigned work. Claim other necessary work only
+   within delegated assignment authority. Respect dependencies and explicit priority;
+   prefer smaller reversible steps when candidates otherwise have equal priority.
+4. **Fill a planning gap.** If an acceptance criterion is unmet and no task covers it,
+   decompose the authorized outcome into bounded tasks with dependencies and evidence
+   requirements, record them, and take the first ready task. A new goal can start with an
+   empty queue. Necessary fixes and verification belong in scope; unrelated improvements
+   remain proposals. If decomposition exposes a new scope decision, route it and continue
+   any independent work already authorized.
+5. **Execute and verify.** Take the task to a meaningful checkpoint. Run checks appropriate
+   to its acceptance criteria, inspect the results, and correct in-scope failures. Persist
+   a resumable checkpoint before a risky action, context limit, or handoff. Do not mark a
+   task done because it was started, delegated, or merely produced an artifact.
+6. **Close communication obligations.** Use the procedure below. Update the goal record
+   with the next action and actual evidence. If ready work remains, return to step 1 in
+   this turn. Report significant results without making the report an artificial stop.
+7. **When nothing can run, classify honestly.** Verify satisfaction against acceptance
+   criteria, not queue emptiness. Otherwise record waiting, paused, or blocked with the
+   unresolved gate and exact resumption condition, using ms-goal.
+
+## Failure and budget handling
+
+- Diagnose failures before retrying. Retry transient failures only under the tool's
+  documented bounded retry contract or with a concrete changed input. For an uncertain
+  external side effect, reconcile its request/action identifier first.
+- Repeated actions producing no new task evidence require a different justified approach
+  or a recorded blocker. An unchanged registered wait is not a failed attempt; it should
+  yield instead of generating more reports.
+- Track actual usage when available; label estimates and unavailable measurements. Stay
+  within explicit limits and reserve capacity for verification and a checkpoint. Budget
+  exhaustion pauses work; it does not establish completion. Never reset usage by resuming
+  or splitting a task. Ask for an extension only when one is actually needed.
+- If recording fails, preserve recoverable evidence and report the failure. Do not start
+  further effects that require a durable record or claim they were checkpointed.
+
+## Communication and waits
+
+For authorized inbound work, record the change and acknowledge the sender through the
+available approved transport. A reaction or receipt alone does not require another reply.
+For authorized tasking, handoffs, review requests, or decisions, persist any required
+artifact before sending its pointer. Durable storage does not necessarily mean a Git
+commit; follow the repository's commit authority and workflow.
+
+Record request/task id, destination and workspace, exact receipt, expected return event,
+and follow-up owner. Distinguish drafted, queued, delivered, acknowledged, and completed.
+Unknown delivery is not permission to resend; reconcile or follow the transport's retry
+contract. A report to the user is not delivery to another agent. If no transport is
+available, record the unsent request and route the missing capability to the user.
+
+For a wait, record the last observation, condition that ends it, wake mechanism, and any
+deadline plus its escalation owner/action. Verify the mechanism exists. An owner name,
+file entry, or queued draft does not prove that another turn will occur.
+
+- Use existing message delivery for another agent's response. Do not poll its private
+  files or pane. Use an available coordinator's timeout mechanism for overdue requests.
+- Use ms-agent-watch only when installed, supported, and authorized, for external
+  conditions with no existing wake owner. Verify a known-false control and the actual
+  condition, distinguishing pending from errors; handle an already-met condition now.
+  Verify registration, bind to the exact resource/version and destination, and record
+  timeout/delivery behavior. Reuse valid existing watches and retire obsolete ones.
+- Without automatic wake support, a wait is explicitly **manual**: state who must send
+  what reply or resume instruction. A deadline is checked on the next invocation unless
+  an actual timer/coordinator owns it. Do not promise unattended escalation or resumption.
+
+## Checkpoints and reporting
+
+Persist current task, completed evidence, remaining acceptance gates, next concrete action,
+outstanding communication/wait records, ownership, budget, and uncertain outcomes in their
+authoritative records. Keep a compact checkpoint pointing to them; retain unresolved
+obligations and durable history regardless of checkpoint trimming.
+
+Report what changed, its evidence, what happens next, and any decision needed. Use an
+installed reporting format only when the applicable environment requires it. No special
+reporting skill or goal_report tool is required in dev mode. Do not repeat unchanged
+reports unless asked or a scheduled check produces information that matters.
+
+End normally only at verified satisfaction, explicit pause/cancellation, a genuine
+blocker, or a registered automatic/manual wait with no ready work. If execution is forced
+to end while work remains, checkpoint it as incomplete and name the actual resume path;
+never imply that writing `next` scheduled that action.
+
+For bounded dev testing, use
+[ms-goal's execution checks](../ms-goal/references/execution-checks.md).

skills/ms-sdlc/SKILL.md

@@ -0,0 +1,137 @@
+---
+name: ms-sdlc
+description: Use for all software delivery planning, implementation, review, CI, release, deployment, acceptance, and completion decisions.
+disable-model-invocation: false
+---
+
+# Mosaic SDLC
+
+This skill defines the default software delivery lifecycle. Repository contracts and an explicit operator ruling may narrow it. Silence never widens authority or waives a gate.
+
+## Roles and separation
+
+- The product lead owns priority, requirements, delivery status, and product acceptance.
+- The conductor or orchestrator coordinates implementation, review, integration, and deployment.
+- The assigned author owns source changes and test evidence.
+- An independent reviewer verifies the exact candidate. An author never reviews their own change.
+- The operator performs final user acceptance for user-facing work.
+- Domain or intake owners retain their declared data, sourcing, and domain-acceptance responsibilities.
+
+Do not absorb another role because its seat is unavailable. Restore the assigned seat or escalate.
+
+## Delivery sequence
+
+Use these states in order. Report the narrow current state rather than calling intermediate work done.
+
+1. **Intake accepted.** Record the user need, owner, priority, and authority boundary.
+2. **Requirements approved.** Define acceptance criteria, non-scope, dependencies, protected operations, and rollback expectations.
+3. **Plan approved.** Pin the baseline and exact plan. Resolve contradictions before implementation.
+4. **Implementation chartered.** Name the author, reviewer, worktree or branch, issue, allowed paths, test obligations, and forbidden operations.
+5. **Implementation ready for review.** The author supplies an exact clean candidate and reproducible test evidence.
+6. **Implementation approved.** An independent reviewer verifies the exact candidate and all findings are closed or explicitly rejected by the proper authority.
+7. **PR in CI.** Publish only through the approved repository workflow. Run every CI gate implemented on the trusted target branch.
+8. **Merged.** Use the repository's approved merge strategy. Verify the merged tree corresponds to the reviewed candidate.
+9. **Post-merge verified.** Require terminal-green post-merge CI and immutable artifact identity.
+10. **Deployment approved.** Review the immutable deployment pin, environment delta, rollback target, and protected-operation boundary.
+11. **Deployed healthy.** Verify GitOps or runtime convergence, workload health, exact artifact identity, and rollback readiness.
+12. **Product accepted.** Verify the stated acceptance criteria with situational evidence in the target environment.
+13. **Ready for user test.** Give the operator a short test script with expected results. Do not call the feature done.
+14. **User approved.** The operator tests user-facing behavior and explicitly approves it.
+15. **Done.** Update canonical status records only after every applicable gate above passes.
+
+## Planning requirements
+
+A plan must state:
+
+- the user-visible outcome and exact acceptance criteria;
+- the trusted baseline and dependencies;
+- author and independent reviewer roles;
+- in-scope and excluded files or systems;
+- automated, situational, accessibility, security, and hostile-control evidence appropriate to the change;
+- CI coverage and any important checks that CI does not run;
+- deployment, rollback, and user-test procedures;
+- credential, schema, production-data, and irreversible-operation boundaries.
+
+If a requirement is unsafe, contradictory, or materially larger than approved scope, stop. Return it to planning and independent review. A defect correction may stay within the existing charter only when it does not change the approved requirement or authority boundary.
+
+## Interrupted work
+
+Never reset or adopt interrupted work automatically.
+
+1. Preserve the worktree exactly as found.
+2. Return it to the original author.
+3. Have the author inspect the diff and explain its intent.
+4. Reverify the baseline, charter, and candidate provenance.
+5. Run focused checks before continuing.
+6. Record whether the partial work was retained, replaced, or reverted and why.
+
+## Verification and CI
+
+Documentation is not proof of its own claims. Every completion claim cites a reproducible command, file, immutable identifier, or live measurement.
+
+Required verification includes:
+
+- author tests for the changed behavior and relevant regressions;
+- independent exact-candidate review;
+- every CI gate configured on the trusted target branch;
+- feature-specific checks that CI does not run, reproduced independently when practical;
+- branch or PR CI, approved merge, and post-merge CI;
+- immutable build and deployment identity;
+- target-environment product evidence.
+
+Do not imply that CI covers a check it does not execute. An important repeatable missing CI check may justify a separate scoped CI task. Do not smuggle CI expansion into unrelated feature work unless the approved plan includes it.
+
+A failed, missing, or unverifiable gate stops the transition. Diagnose it. Never bypass or relabel it green.
+
+## Deployment and protected operations
+
+Routine deployment may proceed without repeated operator approval only when standing authority explicitly permits it and all required gates pass.
+
+At minimum require:
+
+- independent exact-head approval;
+- green branch or PR CI;
+- approved merge and green post-merge CI;
+- reviewed immutable artifact and deployment pin;
+- deployment health and exact runtime identity;
+- a tested or otherwise verified rollback target;
+- no undeclared schema migration, credential operation, production-data mutation, or irreversible action.
+
+Credentials, schema changes, production-data mutations, destructive actions, and operations outside the approved envelope require their declared approval. For bounded production acceptance, prepare one explicit envelope naming fixtures, allowed mutations, verification, cleanup, and rollback. Any action outside it needs new approval.
+
+A later candidate may combine undeployed changes only when the integration order is explicit, evidence proves every included requirement, unrelated work is excluded, and rollback remains clear.
+
+## Product and user acceptance
+
+Automated checks cannot establish all product behavior. Use a real browser, client, API, or runtime when the acceptance criterion concerns layout, interaction, accessibility, timing, integration, or deployment behavior.
+
+Product acceptance confirms the implementation meets the approved criteria. It does not replace user acceptance.
+
+For user-facing work:
+
+1. Deploy the approved candidate.
+2. Complete product acceptance and rollback verification.
+3. Mark it **ready for user test**.
+4. Give the operator exact steps and expected results.
+5. Wait for explicit operator approval.
+6. Mark it done only after approval.
+
+Without operator testing, the user-facing outcome remains unverified. If user testing fails, record the exact observation, reproduce it, and send the correction through implementation, independent review, CI, deployment, and user testing again. Never patch production directly.
+
+For work with no meaningful user-testable behavior, the operator may explicitly waive hands-on testing for that delivery. Never infer a waiver from silence.
+
+## Concurrency
+
+One source-changing feature is the default. Parallel source work requires isolated worktrees, named authors and reviewers, non-overlapping authority, and an explicit integration order. Read-only investigation, planning, and acceptance preparation may proceed concurrently.
+
+## Status and communication
+
+- Report meaningful milestones, decisions, failed gates, scope changes, and protected-operation requests.
+- Keep routine worker transitions within orchestration channels.
+- Keep repository and fleet status synchronized with verified evidence.
+- Preserve another owner's substantive acceptance claims unless coordinated with that owner.
+- Use precise labels such as `implementation approved`, `PR in CI`, `merged`, `deployed`, `ready for user test`, and `done`.
+
+## Definition of done
+
+A change is done only when every applicable requirement, review, test, CI, merge, deployment, product-acceptance, rollback, documentation, and user-approval gate has passed. Missing evidence means not done.