atris 3.35.0 → 3.36.0

package/AGENTS.md

@@ -125,6 +125,41 @@ member -> mission start --verify -> status --status active -> one bounded step -
 - Close: if the verifier passes, run `atris mission complete <id> --proof "<receipt_path>"`; if current-agent work should keep going, repeat status -> step -> tick.
 - Rollout: `atrisos-backend` and `atrisos-web` agents must check active missions before picking work; if no active mission exists and autonomy was requested, create one with owner, verifier, lane, and stop condition first.
 
+## Build Craft — what decides acceptance
+
+Mined from this repo's receipts (803 receipts, 1711 episodes): proofs naming a
+runnable verify command were accepted 670/674 at the gate; 24 of 28 bounces
+named none. These rules are the difference, in priority order:
+
+1. **Name a runnable verify command in every proof**, and run it bare — never
+   `test | tail` or `| grep`; a pipe replaces your exit code with the filter's.
+2. **A task naming a spec file (`atris/features/<name>/idea.md`) is a contract.**
+   Read it before writing code; build the named slice only; use its verify
+   command verbatim. Do not improvise adjacent improvements.
+3. **Zero new dependencies.** This CLI runs on Node built-ins only (fs, path,
+   child_process, readline, https, crypto). A `package.json` dependency change
+   is an automatic bounce.
+4. **New CLI command = router entry too.** A `commands/<name>.js` branch is dead
+   until the name is in `knownCommands` in `bin/atris.js`. When adding an
+   engine, three test files assert the exact profile-name list (runner-command,
+   engine, cli-smoke).
+5. **Output voice:** lowercase CLI output, plain sentences, no em dash
+   character, no ALL CAPS, no ULIDs or test counts on human-facing lines.
+6. **Git discipline:** `git status` first; stage only files you changed; never
+   revert another agent's work; never destructive git; land against
+   `origin/master` (the board measures master, not your launcher branch).
+7. **Final report = files changed + verify command + its exact exit/output.**
+   Judges read the worktree diff, not your prose; an empty report with a clean
+   diff beats a confident report with no diff.
+8. **Update `atris/MAP.md` sections you touched** (file:line refs drift on
+   their own clock; stale refs contradict closed lessons for months).
+9. **Real runtime over mocks:** if you fixed live behavior, the regression test
+   reproduces it against the real runtime, not a mock that can stay green
+   through breakage.
+10. **When your engine dies mid-build (credits, limits), that is a staffing
+    event, not a failure** — leave the worktree intact with a note; the
+    conductor restaffs it.
+
 ## Rules
 
 - [ ] 3-4 sentences max per response
@@ -164,10 +199,12 @@ Load these first:
 - `atris/brain/STATUS.md`
 - `atris/brain/self_improvement_ledger.md`
 - `.atris/state/chat_scan.latest.json`
+- `atris/wiki/concepts/agent-activation-contract.md`
 - `atris/skills/atris/SKILL.md`
 - `atris/PERSONA.md`
 - `atris/MAP.md`
 - `atris/TODO.md`
+- `atris/wiki/index.md`
 
 First-message rule: lead with the move before writing to the operator.
 Purpose: optimize for decision-speed; lead with the move, then use descriptions only when they help the operator act.

package/README.md

@@ -1,6 +1,8 @@
 # atris
 
-**atris** is an operating system for AI work. It turns any repo into a workspace an agent can actually operate: shared context it reads before it acts, a `plan -> do -> review` loop, durable tasks and daily logs, and verification that ends work on a real check instead of a promise.
+**atris**: you say what you want in plain words. atris builds it, checks it, and shows you proof.
+
+Under the hood it is an operating system for AI work. It turns any repo into a workspace an agent can actually operate: shared context it reads before it acts, a `plan -> do -> review` loop, durable tasks and daily logs, and verification that ends work on a real check instead of a promise.
 
 Every owner gets persistent computers to run it:
 
@@ -42,7 +44,7 @@ Then read the workspace's `atris/atris.md` and follow it exactly. `atris.md` is
 - A strict `plan -> do -> review` loop
 - Daily logs, task tracking, feature packs, and project memory
 - Skills, team members, integrations, and cloud sync when you need them
-- A plain-English answer to "what did my AI actually do?" — run `atris recap` (add `--share` for a paste-ready summary backed by receipts)
+- A plain answer to "what did my AI actually do?": run `atris recap`, or `atris recap --share` for a receipt-backed summary you can paste anywhere
 
 ## Critical Files
 
@@ -91,7 +93,7 @@ atris
 
 `atris init` scaffolds the workspace, including `atris/wiki/`. `atris` loads context and hands the workflow off to `atris/atris.md`.
 
-If you're still shaping the idea, use `atris brainstorm`. If you want one bounded mission pursued to proof, use `atris run "<objective>"`. If you want Atris to keep picking the next mission or member until you say stop, use `atris autopilot`. If you want project memory checked for stale pages and missing context, use `atris loop`. `atris activate` surfaces wiki state from `atris/wiki/STATUS.md` when it exists.
+If you're still shaping the idea, use `atris brainstorm`. If you want Atris to finish one job and prove it worked, use `atris run "<objective>"`. If you want Atris to keep picking the next mission or member until you say stop, use `atris autopilot`. If you want project memory checked for stale pages and missing context, use `atris loop`. `atris activate` surfaces wiki state from `atris/wiki/STATUS.md` when it exists.
 
 Core loop: `plan` -> `do` -> `review`
 

package/atris/GETTING_STARTED.md

@@ -1,6 +1,6 @@
 # Getting Started with Atris
 
-Atris turns any folder into a workspace that gets better over time. Integrates with any agent.
+Atris turns any folder into a workspace that gets better over time. It works with any coding agent.
 
 ## Install
 

package/atris/atris.md

@@ -80,6 +80,7 @@ The same discipline for words. Output stays sharp no matter how bloated the cont
 - **Cut filler.** Drop "it's worth noting", "in order to", "leverage", "seamless", "robust", "delve", stacked hedges, and em dashes. `atris slop` flags the prose tells (em-dash, hype-copy) too.
 - **Bound verbosity by information, not context.** Say the load-bearing thing and stop. Length tracks what the reader needs to act, nothing more.
 - **Match the register.** The operator wants the next move; a spec wants the contract; a journal wants one line. Jargon is a lever only when shared: use the reader's precise terms, define a new one once.
+- **Pass both readers.** Run the dual-register test: an ML researcher finds no technical error, and a second-grade teacher can follow the first read. Keep necessary terms, define each new one once, and remove jargon that does not change the decision.
 
 `expected`: this is how an Atris agent writes and builds. Shipping slop or rambling is a failure smell, same as drift or a stale task.
 
@@ -105,6 +106,8 @@ atris task finish <id> --proof "<tests, screenshot, diff, or receipt>"
 atris task review <id> --lesson "<what improved>" --next "<next task>"
 ```
 
+`atris task ready` carries `--result`, the day-one PM sentence of what the human gained; the CLI refuses agent-speak.
+
 Headless agents should add `--json` where available and read
 `.atris/state/tasks.projection.json` for a compact board view.
 

package/atris/policies/day-loop-voice.md

@@ -0,0 +1,102 @@
+# Day loop voice
+
+The day loop helps an operator choose and learn. It does not manage the operator.
+
+This contract comes from the July 8 five-day simulation review recorded on CLI-931. The approved shape was one thing in the morning, a mirror at night, and a real-time ping only when a human signal turns warm. The loop admits sensing mistakes and judges progress by replies, shifts, revenue, and other outcomes.
+
+## Source before sentence
+
+Every claim must come from current operator data or a named receipt. A message may use email threads, calendar events, landed work, shift results, pipeline changes, or money data when those sources are available.
+
+Do not infer effort, mood, intent, or failure from silence. If the evidence is thin, say what is missing or stay quiet.
+
+The generator should receive facts and compose from them. The examples below show structure and judgment. They are not strings to copy into code.
+
+## Shared voice
+
+- Lead with the fact that changes the operator's next move.
+- Use the person's name and the real number when either matters.
+- Give one prepared action. Do not hand back a menu.
+- Sound warm when the evidence is good. Do not manufacture celebration.
+- Admit a bad read in the first sentence, correct the state, and remove the stale ask.
+- Stop after the useful thought. A quiet day does not need motivational filler.
+
+The message fails if it includes internal task ids, mission ids, flags, file paths, stack traces, or implementation jargon. Translate the result into what happened, how the system knows, and what the operator can do.
+
+## Morning one-thing
+
+The morning note chooses the highest-value move supported by current evidence. It should fit on one phone screen and contain:
+
+- the one fact that makes this move matter now;
+- the single move;
+- the action Atris already prepared.
+
+Shape, not template:
+
+> Maya replied overnight and asked for the security summary.
+>
+> Send that before opening a new thread.
+>
+> I drafted the reply from yesterday's approved notes.
+
+If no move clearly wins, say that no priority earned the top slot. Do not promote a random task to avoid an empty message.
+
+## Evening mirror
+
+The evening note reflects the day without grading the person. It names the outcome, shows the pattern in the operator's own numbers, and carries one useful observation into tomorrow.
+
+Shape, not template:
+
+> Two warm threads moved forward; the new cold batch produced no replies.
+>
+> Follow-ups are working better than first touches this week.
+>
+> Tomorrow's prepared list starts with the three people already in motion.
+
+Do not call the day productive, weak, good, or bad. Report what changed. If the system missed an outcome, name the blind spot instead of filling it with activity counts.
+
+## Warm ping
+
+A warm ping exists only because a live human signal created a short decision window. A new reply, meeting change, approval, payment event, or explicit request can qualify. Time passing does not.
+
+Name who moved, what changed, and the prepared response. One ping per signal. If the signal cools or the operator already acted, send nothing.
+
+Shape, not template:
+
+> Devon asked whether the pilot can start Monday.
+>
+> The answer is yes if legal clears the current terms.
+>
+> I drafted the two-line reply and left it unsent.
+
+## Correcting a sensing mistake
+
+Own the error without an excuse or a reassurance paragraph.
+
+Shape, not template:
+
+> I read the thread wrong. Devon already answered the pricing question.
+>
+> I removed that follow-up. The open question is now the start date.
+
+The correction updates the day state before another message is composed. A stale ask must not survive an admitted mistake.
+
+## Outbound gate
+
+Run the shared outbound artifact gate on the final body. Set the coach surface so the stricter rules run:
+
+```bash
+node scripts/outbound-artifact-gate.js --channel email --format plain --coach-surface morning --body-file /path/to/body.txt
+node scripts/outbound-artifact-gate.js --channel email --format plain --coach-surface evening --body-file /path/to/body.txt
+node scripts/outbound-artifact-gate.js --channel email --format plain --coach-surface warm-ping --signal-proof /path/to/fresh-signal.txt --body-file /path/to/body.txt
+```
+
+The coach gate blocks internal identifiers, fake urgency, guilt, nagging, and generic productivity praise. A warm ping also fails without a signal proof file.
+
+The gate cannot judge whether the chosen move is wise or whether a claim is true. Review still checks the source facts, the prepared action, and the acted-on outcome after delivery.
+
+## Review fixtures
+
+Before approving a generator change, review one real or redacted fixture for each surface it changes. The fixture packet names the input facts, final body, outbound gate result, delivery state, and acted-on outcome when known.
+
+Five real days remain the product gate for cloning the loop to another operator. Syntax checks and polished examples do not replace that run.

package/atris/policies/outbound-artifact-gate.md

@@ -46,3 +46,5 @@ node scripts/outbound-artifact-gate.js --channel email --format html --body-file
 ```
 
 The Gmail backend MIME fix is a transport safety net. Agents still need this gate before asking approval or sending.
+
+Day-loop coach messages use the stricter surface rules in `atris/policies/day-loop-voice.md` and pass `--coach-surface`. Warm pings also name a fresh `--signal-proof` file.

package/atris/skills/design/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: design
 description: Frontend aesthetics policy. Use when building UI, components, landing pages, dashboards, or any frontend work. Prevents generic ai-generated look.
-version: 2.0.0
+version: 3.0.0
 allowed-tools: Read, Write, Edit, Bash, Glob
 tags:
   - design
@@ -10,21 +10,23 @@ tags:
 
 # atris-design
 
-Part of the Atris policy system. Prevents ai-generated frontend from looking generic.
+The taste organ of the Atris system. Opinionated: these are Keshav's principles, not general best practices. Prevents ai-generated frontend from looking generic, and improves itself (see "self-improve" at the bottom, it is part of the job, not optional).
+
+Canonical home: `atris-cli/atris/skills/design/SKILL.md` (this file, git-tracked). `atris sync` stamps it into every workspace's `atris/skills/` and `.claude/skills/`. Edit HERE, never a downstream copy: sync will clobber anything written elsewhere.
 
 ## Atris Integration
 
-This skill uses the Atris workflow:
 1. Check `atris/MAP.md` for existing patterns before building
-2. **Read `atris/policies/design-seed.md` first** — it has the project's unique visual identity (fonts, colors, spacing, motion). This is the design DNA. Do not override it with defaults.
-3. Reference `atris/policies/atris-design.md` for full anti-slop guidance
-4. After building, run `atris review` to validate against this policy
+2. **Read `atris/policies/design-seed.md` first** if it exists: it has the project's unique visual identity (fonts, colors, spacing, motion). This is the design DNA. Do not override it with defaults.
+3. Read `.atris/theme.json` if it exists: brand colors and fonts are already decided, use them.
+4. Reference `atris/policies/atris-design.md` for full anti-slop guidance
+5. After building, run the workspace design gate (`npm run audit:design` in atrisos-web, `atris slop` elsewhere) before claiming done.
 
 ## Quick Reference
 
 **Typography:** avoid inter/roboto/arial/system fonts. pick one distinctive font, use weight extremes (200 vs 800). size jumps should be dramatic (3x). use `clamp()` for fluid sizing. use `ch` units for measure (`max-width: 65ch`).
 
-Font alternatives: instead of Inter → Instrument Sans, Plus Jakarta Sans, Outfit. Instead of Roboto → Onest, Figtree, Urbanist. Editorial → Fraunces, Newsreader, Lora.
+Font alternatives: instead of Inter: Instrument Sans, Plus Jakarta Sans, Outfit. Instead of Roboto: Onest, Figtree, Urbanist. Editorial: Fraunces, Newsreader, Lora.
 
 **Color:** commit to a palette. use OKLCH for perceptually uniform colors. tint your neutrals toward your brand hue (never pure gray). never put gray text on colored backgrounds. never use pure black (#000) or pure white (#fff). avoid the AI palette: cyan-on-dark, purple-to-blue gradients, neon accents on dark.
 
@@ -35,45 +37,47 @@ Font alternatives: instead of Inter → Instrument Sans, Plus Jakarta Sans, Outf
 
 **Layout:** break the hero + 3 cards + footer template. no card-in-card nesting. no identical card grids. asymmetry is interesting. dramatic whitespace. use container queries for component-level responsiveness. fluid spacing with `clamp()`.
 
-**Motion:** one well-timed animation beats ten scattered ones. use exponential easing (`cubic-bezier(0.25, 1, 0.5, 1)`), never bounce/elastic. 150-300ms duration. only animate transform and opacity. always respect `prefers-reduced-motion`. no cursor-following lines, no meteor effects, no buttons that chase the cursor.
+**Motion:** one well-timed animation beats ten scattered ones. use exponential easing (`cubic-bezier(0.25, 1, 0.5, 1)`), never bounce/elastic. 150-300ms duration. only animate transform and opacity. always respect `prefers-reduced-motion`. no cursor-following lines, no meteor effects, no buttons that chase the cursor. no pulsing or glowing live-status dots, no looping ambient animations.
 
-**Interaction:** progressive disclosure — start simple, reveal complexity. optimistic UI — update immediately, sync later. every interactive element needs ALL states: default, hover, focus, active, disabled, loading, error, success. don't make every button primary.
+**Interaction:** progressive disclosure: start simple, reveal complexity. optimistic UI: update immediately, sync later. every interactive element needs ALL states: default, hover, focus, active, disabled, loading, error, success. don't make every button primary.
 
-**Hover:** make elements feel inviting on hover (brighten, subtle scale 1.02-1.05). never fade out, shift, or hide content behind hover. hover doesn't exist on mobile.
+**Hover:** make elements feel inviting on hover (brighten, subtle scale 1.02-1.05). never fade out, shift, or hide content behind hover. hover doesn't exist on mobile. no hover lift: a translate-y shift or a scale past 1.05 on every card is the generated-card reflex; the shift breaks the never-move-content rule and the big grow reads as a template.
 
 **Scroll:** never override native scroll. use "peeking" (show a few px of next section) instead of full-screen hero + scroll arrow.
 
-**Responsive:** mobile-first. touch targets 44x44px minimum. no text under 14px on mobile. no horizontal scroll. container queries > media queries for components. adapt, don't amputate.
+**Responsive:** mobile-first. touch targets 44x44px minimum. no text under 14px on mobile. no horizontal scroll. container queries over media queries for components. adapt, don't amputate.
 
 **Accessibility:** 4.5:1 contrast for text, 3:1 for UI (WCAG AA). visible focus indicators always. semantic HTML. never use color alone as an indicator. keyboard nav with logical tab order.
 
-**Hero (H1 test):** must answer in 5 seconds — what is it, who is it for, why care, what's the CTA.
+**Hero (H1 test):** must answer in 5 seconds: what is it, who is it for, why care, what's the CTA.
 
 **Assets:** high-res screenshots only. no fake dashboards with primary colors. no decorative non-system emojis.
 
-**Backgrounds:** add depth. gradients, patterns, mesh effects. flat = boring. but no glassmorphism everywhere — that's AI slop.
+**Backgrounds:** add depth. gradients, patterns, mesh effects. flat = boring. but no glassmorphism everywhere, that's AI slop.
 
 **Hierarchy:** 2-3 text levels max. don't mix 5 competing styles.
 
-**Labels:** never use all-caps UI labels, tracked-uppercase labels, faux small-caps, or eyebrow-style microcopy for ordinary product surfaces. Keshav strongly dislikes this style. Prefer natural title case or sentence case for labels like "Threads", "Active tasks", and "Team"; do not write them as `THREADS`, `ACTIVE TASKS`, or letter-spaced metadata.
+**No all-caps. ever.** never use the `uppercase` tailwind class, `text-transform: uppercase`, or shout-cased copy on eyebrow labels, section headers, buttons, badges, or anywhere else. random capitalized text mid-page reads as average ai-generated slop. if you need a quiet eyebrow label, reach for a smaller size (`text-[11px]`) or a muted color, never caps. write labels in sentence case ("Active tasks", not "ACTIVE TASKS") and let copy render as authored.
+
+**Copy:** no em dashes (the character, U+2014) anywhere in UI copy. no hedge words, no hype adverbs (the "-lessly" family). plain sentences a human would type.
 
-**Visual anti-patterns:** no glassmorphism, no gradient text, no sparklines as decoration, no rounded-rect-with-colored-border, no large icons with rounded corners above headings, no hero metric layout (big number + small label), no modals unless truly necessary. no "claude beige" off-white backgrounds, no instrument serif overuse (the new AI tell), no generic flat tinted backgrounds.
+**Visual anti-patterns:** no glassmorphism, no gradient text, no sparklines as decoration, no rounded-rect-with-colored-border, no large icons with rounded corners above headings, no pastel-tinted rounded icon tile above a feature heading (a small light-colored square holding an icon, repeated down a feature grid; the generated feature-card reflex), no hero metric layout (big number + small label), no modals unless truly necessary, no all-caps eyebrows/labels/headers, no status-dot-plus-eyebrow hero kickers (a pulsing/colored dot next to a small caps/mono label above the headline; keshav's #1 named slop pattern. if a section needs a kicker at all, plain sentence-case text with no dot), no "claude beige" off-white backgrounds, no instrument serif overuse (the new AI tell), no generic flat tinted backgrounds, no near-black slate or gray hero gradient fading into black (the dark premium SaaS template look), no colored glowing drop shadow under buttons or cards (a tinted neon glow, e.g. a purple or blue shadow; keep shadows soft and neutral), no bright two-color gradient fill on buttons or badges (a saturated gradient across different hues like pink to orange or blue to cyan; use one solid brand color), no giant blurred gradient orb glowing behind the hero (the aurora-blob background: a huge soft-blurred colored blob absolutely positioned behind the fold; reads as a template).
 
 ## Vocabulary is the Lever
 
-Designers beat engineers at AI prompting because they own craft language. Name the move precisely: "tighten vertical rhythm," "increase negative space," "make hierarchy bolder here, quieter there." Vague prompts = vague output. Core terms: vertical rhythm, negative space, bolder/quieter, affordances, meta-design, conviction.
+Designers beat engineers at AI prompting because they own craft language. Name the move precisely: "tighten vertical rhythm," "increase negative space," "make hierarchy bolder here, quieter there." Vague prompts = vague output. Core terms: vertical rhythm, negative space, bolder/quieter, affordances, meta-design, conviction. When the operator's wish is fuzzy, translate it into this vocabulary before building, and say the translation out loud so the operator can correct it.
 
 ## Raising Floor vs Ceiling
 
-Use AI to raise the floor (automate the mechanical 80% — scaffolding, grids, state matrices). Spend human attention on the ceiling (last 10-20% — taste, instinct, the unexpected choice). Cognitive delegation, not surrender. AI routes you there; you make the final call.
+Use AI to raise the floor (automate the mechanical 80%: scaffolding, grids, state matrices). Spend human attention on the ceiling (last 10-20%: taste, instinct, the unexpected choice). Cognitive delegation, not surrender. AI routes you there; you make the final call.
 
-## AX — Agentic Experience
+## AX: Agentic Experience
 
 Design for AI agents as users, not just humans. Agents can't see your buttons. They need: speed, clarity, structured output, verbose errors with next steps, edge case coverage, agentic affordances (`llms.txt`, clear `--help`, stable exit codes).
 
 ## Conviction Over Local Maxima
 
-Iterating toward "slightly better" = local maximum (safe, forgettable). Great design is a bet on a global maximum. AI makes the local-max trap worse — you converge on average faster. Subtraction over addition: the strongest move is often deleting something.
+Iterating toward "slightly better" = local maximum (safe, forgettable). Great design is a bet on a global maximum. AI makes the local-max trap worse: you converge on average faster. Subtraction over addition: the strongest move is often deleting something.
 
 ## Anti-Attractors
 
@@ -87,15 +91,41 @@ Taste emerges from constraints. Pick constraints before starting: one font, two
 
 > "if you showed this to someone and said 'AI made this,' would they believe you immediately? if yes, that's the problem."
 
-Fingerprints: inter/roboto, purple-to-blue gradients, cyan-on-dark, glassmorphism, gradient text, hero metrics, identical card grids, bounce easing, dark mode with neon, sparklines as decoration, rounded rectangles with drop shadows, "claude beige" off-white backgrounds, instrument serif overuse, generic flat tinted backgrounds.
+Fingerprints: inter/roboto, purple-to-blue gradients, cyan-on-dark, glassmorphism, gradient text, hero metrics, identical card grids, bounce easing, dark mode with neon, sparklines as decoration, rounded rectangles with drop shadows, "claude beige" off-white backgrounds, instrument serif overuse, generic flat tinted backgrounds, all-caps eyebrow labels appearing out of nowhere.
+
+## Lessons (typed, compounding)
+
+Every entry: id, rule, detector, status. A detector is a regex/command a gate can run, or `judgment` if only a model can catch it. `graduated` means a deterministic gate now enforces it (design-gate.mjs in atrisos-web, `atris slop` in atris-cli); the lesson stays here as the memory of why.
+
+| id | rule | detector | status |
+|----|------|----------|--------|
+| D1 | no purple/violet/fuchsia/lavender palettes | banned-palette class scan | graduated (design-gate) |
+| D2 | no hardcoded neutral tailwind classes, tint toward brand | zinc/gray/neutral/slate class scan | graduated (design-gate) |
+| D3 | no all-caps labels anywhere | uppercase class scan | graduated (design-gate) |
+| D4 | custom components only, no shadcn/radix primitives | radix import scan | graduated (design-gate) |
+| D5 | no pulsing status dots outside loading skeletons | pulse class scan outside loading/skeleton files | graduated (design-gate) |
+| D6 | no arbitrary hex in color utilities, use brand vars | hex-in-color-utility scan | graduated (design-gate) |
+| D7 | no em dashes in UI copy or prose | U+2014 scan | graduated (atris slop) |
+| D8 | no claude-beige backgrounds, no instrument serif as default | judgment | active |
+| D9 | fuzzy wish gets translated to craft vocabulary and echoed back before building | judgment | active |
+
+## Self-Improve (part of the job)
+
+This skill compounds or it dies. The contract, every frontend session:
+
+1. **Capture in the same tick.** When the operator corrects a design choice (a "no", a revert, a fix after landing, a reaction like "that looks AI"), append a typed lesson row above before the session ends. Quote the trigger in the commit/journal, keep the rule one line, propose a detector.
+2. **Graduate detectors.** A lesson with a deterministic detector does not stay prose: add it to the nearest gate (`scripts/design-gate.mjs` CATEGORIES in atrisos-web, `atris slop` rules in atris-cli), then mark the row graduated. The gate is the enforcement; the row is the memory.
+3. **Promote repeat offenders.** A judgment lesson that fires 3+ times gets rewritten into the Quick Reference prose above and its row marked promoted.
+4. **Edit the canonical only.** This file, in atris-cli, committed to git. Then run `atris sync` in each workspace (or wait for the pulse tick) to propagate. Writing to a downstream copy is a lost write.
+5. **Prune.** Fold subsumed lessons, keep this file readable in one sitting. If the lessons table passes ~25 rows, graduate or promote before adding.
+6. **Bump the version** on every content change (progressive: patch for a lesson row, minor for a new principle).
 
 ## Before Shipping Checklist
 
-Run through `atris/policies/atris-design.md` "before shipping" section:
 - can you name the aesthetic in 2-3 words?
 - distinctive font, not default?
-- at least one intentional animation?
-- background has depth?
+- at least one intentional animation? zero pulsing/looping ones?
+- background has depth? not claude beige?
 - hover states feel inviting, not confusing?
 - scrolling feels native?
 - hero passes H1 test (what/who/why/CTA)?
@@ -104,20 +134,14 @@ Run through `atris/policies/atris-design.md` "before shipping" section:
 - WCAG AA contrast (4.5:1 text, 3:1 UI)?
 - works on mobile (44px touch targets, no horizontal scroll, readable text)?
 - respects `prefers-reduced-motion`?
+- zero shout-cased copy? zero em dashes in copy?
 - did you name the moves in craft vocabulary (vertical rhythm, negative space, bolder/quieter)?
 - did you use anti-attractors (named what to avoid, seeded a reference, set a constraint)?
 - if agent-facing: does it have agentic affordances (clear errors, structured output, stable exit codes)?
+- ran the design gate? (`npm run audit:design` / `atris slop`)
+- new operator correction this session? then a new lesson row exists in the canonical and it is committed.
 - would a designer clock this as ai-generated?
 
-## Atris Commands
-
-```bash
-atris            # load workspace context
-atris plan       # break down frontend task
-atris do         # build with step-by-step validation
-atris review     # validate against this policy
-```
-
 ## Learn More
 
 - Full policy: `atris/policies/atris-design.md`

package/atris/skills/endgame/SKILL.md

@@ -62,18 +62,24 @@ After running the three moves, write the result to `atris/TODO.md`:
 **Source:** <inbox-item | wiki-signal | user-prompt> (so we know where it came from)
 ```
 
-2. **Add each REVERSE PATH step as a tagged backlog task** in `## Backlog`:
+**Horizon voice rule (non-negotiable).** The horizon renders verbatim on every boot to whoever opens the workspace: engineer, operator, or a first-day outsider. Write it so a new teammate in any domain gets it on first read: one sentence, plain words, no em dashes, no ids/flags/insider jargon (no "dispatch", "lane", "fast-tier", "receipt path"), and it names the observable proof ("proven the day X happens"). If a term only means something to the people who built the system, translate it or cut it.
+
+2. **Add each REVERSE PATH step as a tagged task — through the task db when one exists.**
+
+**Durable-db workspaces (any repo with `.atris/state/tasks.projection.json` / the `atris task` verb):** markdown task lines written into TODO.md DO NOT SURVIVE — the next `atris task render` regenerates the file from the db and silently wipes them (learned 2026-07-12, lesson `endgame-tasks-must-be-durable-db-rows`; the `## Endgame` header block survives, the tasks vanish). Create each step as a real row instead:
+
+```bash
+atris task add "<step description>" --tag endgame
+```
+
+**Markdown-only workspaces (no task db):** the old inline form is fine:
 
 ```markdown
 - **T1:** <step 1 description> [endgame]
   **Verify:** <deterministic-check>
-- **T2:** <step 2 description> [endgame]
-  **Verify:** <deterministic-check>
-- **T3:** <step 3 description> [endgame]
-  **Verify:** <deterministic-check>
 ```
 
-The tag must be exactly `[endgame]` (parser only matches `\w+`, no colons or hyphens). The slug lives in the section header.
+The tag must be exactly `endgame` / `[endgame]` (parser only matches `\w+`, no colons or hyphens). The slug lives in the section header.
 
 3. **Always append an RSI audit as the final task:**
 

package/atris/skills/engines/SKILL.md

@@ -1,19 +1,20 @@
 ---
 name: engines
-description: "Dispatch coding work to an installed terminal agent — Codex, Cursor, Devin, or Atris Fast — as an interchangeable worker engine. Claude orchestrates: writes the bounded prompt, the engine builds, Claude verifies and lands. Triggers on: use codex, use cursor, use devin, use atris, engine, dispatch to, worker agent, second opinion build."
-version: 1.1.0
+description: "Dispatch coding work to an installed terminal agent — Codex, Cursor, Devin, Grok, or Atris Fast — as an interchangeable worker engine. Claude orchestrates: writes the bounded prompt, the engine builds, Claude verifies and lands. Triggers on: use codex, use cursor, use devin, use grok, use atris, engine, dispatch to, worker agent, second opinion build."
+version: 1.2.0
 tags:
   - engines
   - codex
   - cursor
   - devin
+  - grok
   - atris
   - orchestration
 ---
 
 # Engines — interchangeable terminal workers
 
-One contract, four engines. The orchestrator (you, Claude) writes a bounded task prompt, dispatches it to an engine, then **independently verifies, lands, and pushes** the result. Engines never self-certify.
+One contract, five engines. The orchestrator (you, Claude) writes a bounded task prompt, dispatches it to an engine, then **independently verifies, lands, and pushes** the result. Engines never self-certify.
 
 ## Invocation
 
@@ -21,7 +22,8 @@ One contract, four engines. The orchestrator (you, Claude) writes a bounded task
 |--------|---------|-------|
 | Codex | `node "${CLAUDE_PLUGIN_ROOT}/scripts/codex-companion.mjs" task --background [--write] "<prompt>"` (via codex plugin / codex:codex-rescue agent) | Poll with `status`, fetch with `result <job-id>` |
 | Cursor | `cursor-agent --trust -p "<prompt>"` (run from the target repo) | Headless print mode; `--trust` required for non-interactive |
-| Devin | `devin -p --permission-mode dangerous -- "<prompt>"` (run from the target repo) | Default permission mode is read-only for writes — build work NEEDS `--permission-mode dangerous`, so only run it in an isolated worktree. Also `devin cloud` for sessions that outlive this machine |
+| Devin | `devin -p --permission-mode dangerous -- "<prompt>"` (run from the target repo) | Default permission mode is read-only for writes — build work NEEDS `--permission-mode dangerous`, so only run it in an isolated worktree. Also `devin cloud` for sessions that outlive this machine. Supports `--model swe-1.7` |
+| Grok | `grok --always-approve -p "<prompt>"` (run from the target repo) | Headless single-turn via `-p`; default model grok-4.5. Very fast on lookups (~10s, reads MAP first). Great for quick second opinions; use `--best-of-n <N>` for tricky bounded builds. Uses grok.com login |
 | Atris Fast | `atris chat --print "<prompt>"` (run from the target repo; equivalently `ax --fast --print`) | Headless JSON result `{ok, model, output, durationMs}`; exit 0 = ok. Serves via the api.atris.ai fast lane (glm-5.2) with a local tool runtime scoped to the cwd — reads, greps, small verified edits. ~1% of frontier cost, typical turns 5–40s |
 
 ## Picking an engine
@@ -29,9 +31,24 @@ One contract, four engines. The orchestrator (you, Claude) writes a bounded task
 - **Codex** — deep root-cause work, long autonomous builds, second-opinion diagnosis. Slowest; runs sandboxed.
 - **Cursor** — fast bounded edits and refactors in a single repo.
 - **Devin** — multi-step feature work; use `cloud` when the run should survive laptop sleep.
+- **Grok** - fastest frontier lookups and quick second opinions (grok-4.5, ~10s; reads MAP first); use `--best-of-n` for tricky bounded builds. Uses grok.com login.
 - **Atris Fast** — cheap bounded lookups, single-file facts, small verified edits, high-volume fan-out (ten questions = ten `--print` calls at pennies). Not for multi-file features or long builds. Use it before burning a frontier engine on grunt work.
 - Parallel builds across repos: one engine job per repo, never two engines writing the same checkout.
 
+## Models worth pinning (verified live 2026-07-09)
+
+Each engine CLI can pin a specific model. Current best picks:
+
+| Engine | Flag | Best models today |
+|--------|------|-------------------|
+| Devin | `--model swe-1.7` | `swe-1.7` (free right now: use it as the volume executor for parallel bounded slices), `swe-1.7-lightning` for speed |
+| Cursor | `--model grok-4.5-xhigh` | `grok-4.5-xhigh` / `grok-4.5-fast-xhigh` for second-opinion builds, `composer-2.5` for fast edits; parameterized Claude via `'claude-opus-4-8[effort=high]'`; `--list-models` shows the full menu |
+| Grok | (default) | `grok-4.5` default, `grok-composer-2.5-fast` for speed |
+| Codex | (plugin default) | rides the codex plugin's pinned model |
+| Atris Fast | (fixed) | api.atris.ai fast lane |
+
+Re-verify this table when a lab ships a new model: run each CLI's model-list command, smoke one lookup, and update the row. Free-tier windows (like swe-1.7 now) are the moment to fan out volume work.
+
 ## Atris Fast runtime requirements (verified live 2026-07-03)
 
 - Must run from an **initialized Atris workspace** (an `atris/` folder) under an allowed workspace root (e.g. `~/arena/*`). `atris chat --print` outside one exits 1 with "Run atris init"; `ax --fast --print` outside an allowed root fail-closes with `{ok:false, error:"workspace_path must be under an allowed local workspace root"}`.
@@ -48,6 +65,7 @@ One contract, four engines. The orchestrator (you, Claude) writes a bounded task
 
 - **Codex sandbox cannot reach github.com and may get read-only repo access.** Expect temp clones / `git format-patch` fallbacks under `/private/tmp`. Apply patches in a fresh worktree, re-run the verify command yourself, then push.
 - Cursor and Devin run unsandboxed — still re-run the verify command yourself before pushing.
+- Long Devin runs (5+ min) can return empty stdout even when the build fully succeeded — judge by `git status` and the diff in its worktree, never by the printed report.
 - Atris Fast answers are model output over a real tool runtime — treat `output` as a claim, spot-check the cited file:line, and re-run any verifier yourself before acting on it.
 - Engine task DBs and receipts written inside a sandbox are snapshots; reconcile against the live `atris task` plane after landing.
 - A stalled job (no log output for 30+ min) gets cancelled and taken over; don't wait on it. Atris Fast turns that exceed ~60s have hung — kill and retry once with a tighter prompt.

package/atris/skills/fable-method/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: fable-method
+description: Working method distilled from Claude Fable 5 for daily-driver models (Opus, Sonnet). Use at session start, before any multi-step task, or when output feels shallow, hedged, or prematurely "done". Triggers on fable method, think like fable, deep pass.
+version: 1.0.0
+tags:
+  - meta
+  - method
+  - handoff
+---
+
+# Fable Method
+
+A handoff doc from the strongest model to the daily driver. Raw capability does not transfer; process does. These are the habits that made the difference observable, written as checks a smaller model can actually run.
+
+## The core loop
+
+1. **Read the whole brief first.** Every constraint, every file named, the goal behind the ask. Do not start executing on the first sentence.
+2. **Sweep context in parallel.** Batch all independent reads and searches into one round. Serial exploration is the top time sink.
+3. **Size the real task.** If it touches 10 files, plan for 10. Never quietly shrink scope to what feels comfortable and then report done.
+4. **Execute in one deep pass.** Hold the plan, work through it, note deviations as you hit them instead of stopping to ask.
+5. **Verify against reality.** Real command, real data, real terminal. A green mock proves nothing (the readline PTY bug lived behind green mock tests for weeks).
+6. **Report outcome first.** First sentence says what happened. Receipts (command plus output) beat adjectives.
+
+## Non-negotiables
+
+- "Done" requires a receipt: the command you ran and what it printed. No receipt means you say "built, not yet verified".
+- Localize uncertainty. "X works (tested), Y I have not checked" beats hedging the whole answer.
+- "Are you sure?" is a request to enumerate concrete failure modes (empty input, race, 500, missing file, off-by-one), not a signal to flip. Update only on new evidence.
+- Verify references at the moment of use. If a doc names a file or flag, confirm it still exists before acting on it. Stale docs get fixed or flagged, not obeyed.
+- Prefer deletion. The best fix removes code. No just-in-case features, no scattered TODOs.
+- Judge and worker stay separate. The pass that verifies never patches; it opens a task.
+
+## Dispatched work
+
+Never end your turn while a build you dispatched (codex, cursor, any engine) is still running. "Standing by" or "polling in the background" ends your run and orphans the build. Poll in the foreground: loop sleep-plus-status-check until it completes, use the wait to prep the next bounded prompt, then verify and land. Your turn ends when every assigned item is shipped-with-proof or blocked with a named reason.
+
+## Briefing engines (codex, cursor, any headless builder)
+
+Learned from a night of live dispatches: engines one-shot well or fail on the brief, almost never in between.
+
+- **Pin the engine by name.** When the operator names a tool or engine, that is a constraint, not a suggestion. A brief that leaves the engine open gets the default, and the operator interrupts.
+- **The brief is: goal, exact files with line refs you verified, Done:, Check:.** Every clean one-shot tonight had all four; every failure was missing one.
+- **Own the git rules explicitly.** Say who commits. If your wrapper lands the work, tell the engine "commit on this branch, never push, never create branches". Engines left ungoverned will auto-commit with foreign trailers and push.
+- **Never let a prompt cd into a repo root.** Engines work in isolated worktrees only; a prompt that targets the primary checkout strands unstaged edits on the operator's branch.
+- **Diff-review the draft before landing.** Judge and worker separation is not ceremony: two real defects (a normalizer silently stripping file content, a fake-green landing) were caught only because the verifier read the diff instead of trusting the report.
+
+## Operating hygiene
+
+- **Never pipe a verify command through anything that masks its exit code.** `cmd | tail` exits with tail's status; you will read green on red. Capture to a file, then check exit and summary separately.
+- **Run state-mutating CLI commands from the repo root that owns the state.** cd-chains that end in another repo or a worktree hit the wrong task db and fail confusingly.
+- **Prefer the tool's own stop verb over kill.** A process that prints "stop anytime: X stop" gets X stop; kill leaves half-landed work for someone to salvage.
+- **When a discipline rule is violated twice, convert it into a mechanism.** Doctrine asks; code enforces. The parked-foreman rule became a blocking dispatch command; the isolation rule became a thrown error.
+
+## Stuck protocol
+
+Never retry the same failing action a third time. Write down three concrete hypotheses for the failure, then run the cheapest test that discriminates between them. If none survive, say what you ruled out and what input you need.
+
+## Memory
+
+After a session with a real lesson, write one fact per file to memory or the journal: what was non-obvious, why it matters, how to apply it next time. Prose logs do not compound; typed facts do.
+
+## For the operator
+
+- One big brief beats 20 micro-instructions. Put all background and constraints in the first message.
+- Over-granular instructions backfire on capable models. State the goal and the constraints, not the keystrokes.
+- Default thinking effort high; save the max tier for genuinely intricate work.