Score for Aesthetic Computer & Pals #

Directed by @jeffrey.

Start with the current task #

This is the shared instruction source. AGENTS.md points here; CLAUDE.md imports it. Keep tool adapters thin. Do not add a second copy in CODEX.md.

Resolve ENVIRONMENT.md at session start and when the host or launcher changes. A macOS terminal uses its local shell; Emacs/fishy applies only in the Emacs environment. Recheck the actual cwd, branch, dirty files and available tools when resuming a prox. Carry forward the objective and accepted corrections; refresh machine and checkout assumptions.

Read WORKFLOWS.md for compushloy, oskieploy, prox and other shared terms. Long command recipes, architecture and diagnostic references live in OPERATIONS.md; player entry points live in README.md.

Task routes #

Load the guides for the task and touched paths, then re-evaluate when scope changes. Nested SCORE.md files are explicitly scoped guides; their filename alone does not make every agent load them. Ant colony rules apply to colony work, not every interactive contribution. Only @jeffrey may edit ants/mindset-and-rules.md.

Use node toolchain/instructions/context.mjs --route <name> --path <path> to list the required guides, or add --print to read one deduplicated bundle. Multiple routes and paths may be supplied. The manifest is toolchain/instructions/routes.json.

Task	Route	First guide
Code or foundational libraries	`code`	HAND.md
JavaScript piece / canvas layout	`piece`	SCREEN.md and piece API
KidLisp	`kidlisp`	kidlisp/SCORE.md
Papers / scholarly research	`papers`	papers/SCORE.md, then Platter, prior papers and evidence
Lith or session deployment	`release`	WORKFLOWS.md, lith/README.md
Native OS / hardware	`native`	fedac/native/SCORE.md
Fleet / macOS host	`fleet`	toolchain/macos/SCORE.md
Prox continuity	`prox`	WORKFLOWS.md
Ant colony	`ants`	ants/mindset-and-rules.md

Use focused validation appropriate to the change. A listed build/test command is a recipe, not a requirement to run every suite. Host budgets still apply. node toolchain/instructions/context.mjs --doctor checks adapters, guide paths, root size and installed hooks without installing hooks or running builds.

Host and release boundaries #

On Blueberry, work in /Users/jas/Developer/fuser* must not run typechecks, builds, full suites, Turbo, workspace lint, or hooks that invoke them unless Jeffrey explicitly opts in to that exact command in the current conversation. Use lightweight inspection and --no-verify for Fuser commits instead.

Swift builds use the guarded ~/.local/bin/swift; Slab iteration uses slab/menubar-swift/build-dev.sh, with install.sh for the final install. Media work uses the ffmpeg/ffprobe QoS shims. Do not bypass these budgets except when deliberately diagnosing the guard or benchmarking the bypass.

Production releases must identify the intended branch and commit, deploy that pushed revision, and verify the served result. Shared arena physics must match between lith and the session server. Check installed hooks before an explicit release so a background hook and a manual command do not race. Do not call a published OTA flashed, an offline console current, or a pushed commit deployed. See WORKFLOWS.md for completion evidence.

Context Resolution Order #

Interpret names and requests in this order unless the user explicitly points elsewhere:

Our seat / local fleet — machines, displays, prompt rocks, host tooling, and the immediate development environment. Names such as panda, chicken, neo, and blueberry mean machines first.
Aesthetic Computer — this monorepo, its pieces, services, and production system.
Client context — client infrastructure or projects only when the conversation makes that context clear; resolve their details through aesthetic-computer-vault.

Do not interpret a known machine name as an Aesthetic Computer piece until the seat/fleet meaning has been ruled out.

Editorial Output Score — Wordcrust + Slidecop #

These rules apply to authored output across personal and client work.

Wordcrust #

Wordcrust is explanatory text accumulating around the thing: marginalia, duplicated labels, decorative headings, restatements, throat-clearing, and LLM-sounding description. Remove it before delivery.

No marginalia by default. Do not add eyebrows, kickers, explanatory subheads, side notes, callout prose, or summaries unless they add information needed to use, verify, attribute, access, or safely interpret the artifact.
One visible label per idea. Do not restate a title in a subtitle, body, badge, diagram label, or callout.
Prefer the artifact, evidence, or action over prose about it. If deleting a text element changes neither meaning nor action, delete it.
Preserve necessary facts, source attribution, accessibility text, safety constraints, and the user's voice. Concision is not vagueness.

Slidecop #

A slide passes Slidecop only when it works at conference-room distance.

One claim per slide.
No marginalia.
Essential type is large, high-contrast, and readable in a 10%-scale preview.
Evidence dominates the frame. Select and crop screenshots to the exact useful state; never shrink a whole interface into an unreadable postcard.
Inspect the rendered slide or video, not only its source. Fail any slide whose claim or evidence requires zooming.

Design proposal routing #

A proposal with multiple directions must make the choice visible before it is explained.

Shared foundations are not directions. Name the common entry, then show the point where the routes diverge.
Each direction owns a distinct visual grammar: density, image scale or ratio, typography, primary action, and explicit exclusions. If two routes cannot be distinguished in silent thumbnail view, collapse or redesign them.
Put one route map before the options and repeat a miniature on every routed page. Highlight the current path; keep inactive paths visible for orientation.
State each route as a narrow contract: intended use, governing visual rule, and what it must never absorb from the other routes.
Inspect the map and the differences at 10% scale. The active route and the visual character of each option must remain legible without reading body copy.

Pull Request Score #

Fuser branch routing #

For fuserstudio/fuser, authored work lives directly in the upstream repository on a flat jeffuser-<slug> branch. jeffuser is the branch namespace; there is no separate jeffuser or whistlegraph/fuser fork. The authenticated GitHub author may remain whistlegraph.

Never create or publish Fuser branches under agent/, codex/, or another tool identity.
Before opening a Fuser PR, verify that the head matches ^jeffuser-[a-z0-9][a-z0-9-]*$, the head repository is fuserstudio/fuser, and the base is staging unless the user explicitly names another base.
If a PR was opened from the wrong head, publish the same reviewed commit on a compliant jeffuser-* branch, open and verify the replacement PR, then close the obsolete PR and delete its remote branch. GitHub cannot change an open PR's head branch in place.

PostHog account boundary #

The Codex PostHog OAuth connection authorized as mail@aesthetic.computer belongs only to the Aesthetic Computer PostHog organization. Never use that connection, its project, or its data for Fuser work. Fuser PostHog access requires a separate explicit invitation and authorization from Fuser; until then, restrict Fuser analytics work to repository code and user-provided evidence.

Aesthetic Computer PostHog complements existing Lith, Silo, Mongo, Google Analytics, MCP, and local-tool telemetry; it does not replace those operational channels. Do not send prompt or session content, chats, mail, contacts, fleet host details, local files, secrets, or raw MCP payloads to PostHog by default. Describe those systems as product context without exporting their private data. New local-tool or MCP analytics must use an explicit, minimized, opt-in event schema.

Keep a small PR terse. When the work is a recovery, migration, or design change that benefits from a fuller review story, use this structure:

Lead with the developer story: the concrete incident, who needs what, and why it matters. A substantial PR may title it ## 🧑‍💻 Developer story.
Add ## 🔗 Recovery chain when the work follows earlier accepted PRs, and state the responsibility contributed by each one.
Prefer one narrow, top-to-bottom Mermaid flowchart TD with short labels. Add another diagram only for a distinct layer that prose cannot explain as clearly.
Use color sparingly inside Mermaid through semantic classDef styles. GitHub does not reliably color ordinary Markdown text, so do not use HTML or CSS hacks. For textual emphasis, prefer a durable blockquote such as > 🛡️ **Core safety rule:** ….
Sprinkle a few semantic emoji before major headings for navigation (🔗, 🔄, 🛡️, 🎯, ✅). Do not mark every heading or decorate body prose.
Make safety invariants, exact validation, known limits, and deliberately out-of-scope work explicit. Use concrete identifiers when they help readers verify the story, but never expose secrets or irrelevant private host data.

The reading order is story → related work → simple flow → safety → evidence → limits. The complexity of the work must earn the length and diagrams.