# Mosaic Universal Agent Standards

This file is the canonical standards contract for agent sessions on this machine.

Master/slave model:

- Master: `~/.config/mosaic` (this framework)
- Slave: each repo bootstrapped via `mosaic-bootstrap-repo`

## Execution Model

1. Load this file first.
2. Load project-local `AGENTS.md` next.
3. Respect repository-specific tooling and workflows.
4. Use lifecycle scripts when available (`scripts/agent/*.sh`).
5. Use shared tools/guides from `~/.config/mosaic` as canonical references.

## Non-Negotiables

- Data files are authoritative; generated views are derived artifacts.
- Pull before edits when collaborating in shared repos.
- Run validation checks before claiming completion.
- Apply quality tools from `~/.config/mosaic/tools/` when relevant (review, QA, git workflow).
- For project-level mechanical enforcement templates, use `~/.config/mosaic/tools/quality/` via `~/.config/mosaic/bin/mosaic-quality-apply`.
- For runtime-agnostic delegation/orchestration, use `~/.config/mosaic/tools/orchestrator-matrix/` with repo-local `.mosaic/orchestrator/` state.
- Avoid hardcoded secrets and token leakage in remotes/commits.
- Do not perform destructive git/file actions without explicit instruction.
- Browser automation (Playwright, Cypress, Puppeteer) MUST run in headless mode. Never launch a visible browser — it collides with the user's display and active session.

### Output standards (writing + code)

- Technical documentation follows **MOS-STE** (Mosaic Simplified Technical English — an adapted ASD-STE100 profile): short sentences, one instruction per sentence, active voice, one word per meaning, one term per concept. Full rules: `~/.config/mosaic/guides/WRITING-STYLE.md`.
- Apply MOS-STE **hardest to verification artifacts** (acceptance criteria, witness predicates, gate/alarm conditions). There an ambiguous term produces a false green, not just a confused reader.
- Source code follows the **Google Style Guide** for the language.
- User-facing comms follow the user's declared `communicationStyle` in `USER.md` "Communication Preferences" (`direct` | `friendly` | `formal`, default `direct`); `guides/WRITING-STYLE.md` §5 maps each value to output. The documentation standard does not change with user preference.
- **Carve-out:** MOS-STE does NOT apply to content that must carry a specific human voice (letters, personal or marketing prose, voice-matched output). A declared voice profile wins.

### Secrets handling (HARD RULE)

- Vault is the canonical source-of-truth for every secret in every environment. No exceptions.
- For k8s workloads, the default read path is **External Secrets Operator → k8s Secret → env var** (`secretKeyRef`). The app reads standard env vars; no Vault client in app code.
- Direct-Vault clients in application code are **opt-in only**, justified per-app by a documented dynamic-secrets requirement (e.g., DB rotation, AWS STS). Default to ESO. Document the justification in the project's README under "Secrets architecture".
- `${VAR:-default}` fallback syntax in any deployment configuration (compose, k8s manifests, Helm values, env files committed to git) is **forbidden** for required values. Use `${VAR:?VAR is required}` to fast-fail. Defaults are allowed only for true conveniences (e.g. `${PORT:-3000}`) and MUST be tagged `# safe-default: <reason>` so a reviewer can confirm the intent.
- `.env` files in production deployment paths are **forbidden**. `.env.example` and `.env` in local-dev paths are fine.
- App startup MUST validate required secrets against a schema (zod / pydantic / equivalent) and exit non-zero on missing required values. Never run with defaulted weak fallbacks.
- New apps: bootstrap checklist (see `~/.config/mosaic/guides/BOOTSTRAP.md`) MUST include Vault path provisioning + `ExternalSecret` manifest + README declaring the Vault path and required keys.

## Session Lifecycle Contract

- Start: `scripts/agent/session-start.sh`
- Priority scan: `scripts/agent/critical.sh`
- End: `scripts/agent/session-end.sh`
- Limitation logging helper: `scripts/agent/log-limitation.sh "Title"`

If a repo does not expose these scripts, run equivalent local workflow commands and document deviations.

## Multi-Agent Safety

- Coordinate through git pull/rebase discipline.
- Do not auto-resolve data conflicts in shared state files.
- Keep commits scoped to a single logical change set.

## Model Tiering

Model choice is a standard, not a preference. Delegating a mechanical grep to a
frontier reasoning model wastes budget; sending a security review to a cheap tier
produces a review that passes and proves nothing. Both are defects.

Tiers are named by **capability class**, so the standard survives a model
generation. An operator binds each class to a concrete model id.

| Class         | Use for                                                                                   |
| ------------- | ----------------------------------------------------------------------------------------- |
| `search`      | grep/glob, file location, status and health checks, one-line mechanical edits             |
| `build`       | feature implementation, test writing, bugfixes, routine refactors                         |
| `judge`       | code review, planning, API/compat-sensitive changes                                       |
| `adversarial` | security review, ambiguous architecture, anything where a wrong "looks fine" is expensive |

Rules:

1. **Start at the cheapest class that can do the task; escalate on evidence, not
   on nerves.** Omitting a tier is not neutral — it inherits the caller's model,
   which is usually the most expensive one.
2. **Compat-sensitive work escalates one class.** A change that must interoperate
   with an existing contract is judged, not just built.
3. **A tier assignment is benchmarked, not asserted.** Move a task class to a
   cheaper tier only against a blind A/B on real work from this codebase, ranked
   by someone other than the author. "It seemed fine" is not evidence.
4. **Reviewer independence beats reviewer size.** An `adversarial` verdict from
   the model that wrote the code is not a second opinion (see Constitution gate 16).

### Where the binding lives

The class→model map is operator configuration, never framework source: model
availability, cost, and quotas differ per operator and per host.

Resolution order, first hit wins:

1. the config service (DB-backed, surfaced and editable in the Mosaic webUI)
2. a local operator file (`STANDARDS.local.md`, or `policy/` where the runtime
   injects it)
3. the framework default — the class names above, with no binding

Only layer 1 is auditable across a fleet, so it is the target end state; layers 2
and 3 exist so a host with no config service still runs. A local override that
silently disagrees with the config service is drift — the same failure class the
tool-index gate exists to catch, and it belongs in `mosaic doctor`.

## Prompting Contract

All runtime adapters should inject:

- `~/.config/mosaic/STANDARDS.md`
- project `AGENTS.md`

before task execution.

Runtime-compatible guides and tools are hosted at:

- `~/.config/mosaic/guides/`
- `~/.config/mosaic/tools/`
- `~/.config/mosaic/profiles/` (runtime-neutral domain/workflow/stack presets)
- `~/.config/mosaic/runtime/` (runtime-specific overlays)
- `~/.config/mosaic/skills-local/` (local private skills shared across runtimes)
