Writing code got cheap. Trusting it didn’t.

## Ownership Zone The architecture, configuration, and enforcement of data boundaries between independent tenants across the platform. This includes tenant identification and routing at the request boundary, schema-level isolation mechanisms, query filtering and access control, credential and secret scoping per tenant, and the visibility of isolation health to non-engineers through audit trails and breach detection. The steward owns the floor that prevents one tenant from reading, writing, or inferring the state of another. ## Rubric - **Tenant identity at the edge** — Every request carries a verified tenant identifier before any business logic executes. This is the floor the rest of the rubric stands on: until tenant identity is established and immutable at the boundary, downstream isolation is fiction. Tenant context is extracted from a single source of truth (JWT claim, session, header) and cannot be overridden by request parameters or inferred from data shape. - **Query-level filtering enforcement** — All data queries automatically scope to the request tenant without relying on caller discipline. Queries fail closed rather than silently returning cross-tenant data when a filter is missing. This sits on top of verified tenant identity: only meaningful once you know which tenant made the request. - **Credential and secret isolation** — API keys, database credentials, third-party tokens, and encryption keys are scoped per tenant and cannot be accessed by other tenants. A compromised credential in one tenant does not grant access to another tenant's resources or secrets. - **Schema-level boundaries** — The data model itself enforces tenant ownership: foreign keys, row-level security policies, or partition keys make it structurally impossible to query across tenant boundaries. A schema change that removes a tenant column or constraint surfaces immediately as a breaking change, not as a latent vulnerability. - **Isolation testing and validation** — Automated tests verify that queries with one tenant's credentials cannot read, write, or infer the existence of another tenant's data. Tests cover both happy-path isolation and edge cases like concurrent requests, batch operations, and error states. Isolation is not assumed; it is measured. - **Audit and breach visibility** — Cross-tenant access attempts, credential misuse, and isolation violations are logged and surfaced to non-engineers without requiring code review. A support team member or operator can answer whether a tenant's data was accessed by another tenant without paging an engineer, and breach detection runs on a known cadence.

## Ownership Zone Owns the surface that a newcomer hits in their first hour with the project: the README and any top-level docs that describe what the project is, the setup and run instructions, the prerequisites and toolchain expectations, the workspace and directory orientation, and the contributor guidance for making a first change. Responsible for keeping the stated identity of the project (name, purpose, domain, audience) aligned with what the code actually is, and for keeping installation, build, and run paths walkable from a clean machine. Covers the handoff from stakeholders and casual readers (what is this?) through to first-time contributors (how do I run it and where do I edit?). Does not own deep architectural docs, API references, or runtime operational guides — only the on-ramp. ## Rubric - **Truthful project identity** — The floor the rest of the rubric stands on: if the README describes a different project than the one in the repo, every other dimension is grading instructions to the wrong place. The stated name, purpose, domain, and tech stack match what a reader would conclude after ten minutes in the source tree, and template/scaffold residue from the project's origin has been replaced rather than left as quiet lies. - **Walkable setup path** — Only meaningful once identity is truthful, because setup steps for the wrong project waste the newcomer's trust before they hit a real error. A reader on a clean machine can go from clone to running app by following the documented steps in order, prerequisites are named with versions where versions matter, and the steps actually executed by the maintainer match the steps the doc tells a stranger to run. - **Orientation to the shape of the repo** — Sits on top of truthful identity: a newcomer who knows what the project is still needs to know where things live before they can contribute. The doc names the major directories, the workspace or monorepo layout if any, and where a first change is likely to go — so a contributor doesn't have to reverse-engineer the structure or guess which folder owns which concern. - **First contribution on-ramp** — Becomes possible once setup and orientation are in place. Conventions a contributor will trip over (formatting, commit style, branch flow, how to run tests or checks locally) are stated where a contributor will actually look, and the gap between running the app and submitting a change is short and explicit rather than tribal. - **Stakeholder legibility** — A non-engineer landing on the repo — a collaborator, a domain stakeholder, a curious visitor — can answer what is this, who is it for, and is it alive without reading code or asking the maintainer. The README opens with the answer to those questions rather than burying them under build badges and install commands, and the project's audience is named, not assumed. - **Drift resistance** — The capstone that keeps every dimension above honest over time: docs that were correct at one commit silently rot as the code moves. Onboarding content has a known owner and a known cadence for re-walking the path from scratch, changes that invalidate setup instructions are caught close to when they happen rather than discovered by the next newcomer, and the gap between code reality and documented reality is treated as a real defect rather than a cosmetic one.

## Ownership Zone Inngest step-function correctness across lib/inngest/workflows/: step boundaries, replay-safe state flow, idempotent side effects, and early-return ordering — ensuring every workflow produces correct results on both the initial run and any subsequent retry or replay. ## Rubric - **Step-return state flow** — State that must survive across steps is returned from step.run and captured in outer scope, never written by mutating a closure-captured variable. On replay, memoized step results are substituted without re-executing the callback, so mutations silently disappear; the steward flags any `let x = ...; step.run(..., () => x = ...)` pattern where x is read in a later step. - **Step boundary granularity** — Per-entity work (per-steward, per-concern, per-PR comment) is split into idempotent per-entity step.run blocks rather than bundled into one multi-side-effect step. Bundled steps cannot partial-retry, so one transient failure re-executes all side effects on replay or skips them all on memoized return. - **Idempotency of side effects** — GitHub API calls, check-run posts, PR comments, DB writes, and PostHog captures inside step.run are either safe to re-execute on retry or guarded by a deterministic key (SHA, comment marker, idempotency token). Replays and retries must not produce duplicate comments, double-counted events, or conflicting check runs. - **Early-return and failure-path ordering** — Detection and dispatch logic (PR-merge detection, scope filtering, installation health, debounce) runs before early-return branches, and failure telemetry covers early-error exits — not just the happy path. The steward flags happy-path-only instrumentation and skip-paths that swallow signals the user expects to see. - **Same-SHA persisted state reuse** — Persisted state read across steps (review verdicts, slot acquisitions, debounce gates, claim linkage) is correctly scoped to the head SHA and replay-safe. Stale persisted state from a prior head must not be reused on a new SHA, and a same-SHA acquire-miss must not silently carry forward a verdict that no longer reflects the diff.

## Ownership Zone Every moment where a person interacts with the application and forms a judgment about whether it feels professional, responsive, and trustworthy. This covers the full surface of user-triggerable actions and their feedback (toasts, confirmations, loading states, status changes, error surfaces), the visual and interaction language across screens (layout consistency, density, typography, affordances), the navigational and informational scaffolding that lets a user orient themselves, and the empty/error/edge states that decide whether the product feels finished or half-built. The steward owns the experiential contract end-to-end: from the instant a click happens to the moment the user is sure something happened, and from first impression of a screen to the user's confidence that they know what to do next. ## Rubric - **Action acknowledgement** — Every user-triggered action produces a visible, timely signal that the system received it and is acting on it: a loading indicator, a toast, a status change, or a confirmation. This is the floor the rest of the rubric stands on — without it, the user is guessing whether the product is broken, and judgments about polish, hierarchy, or stakeholder visibility are grading a surface the user has already lost trust in. The failure mode is the silent click: the action fired, the state changed somewhere, and the user has no idea. - **Feedback proportionality** — Sits directly on top of action acknowledgement: once feedback exists, the question is whether it matches the weight of the action. Trivial actions get lightweight signals, destructive or irreversible actions get explicit confirmation, long-running actions show progress rather than a frozen button, and errors surface what went wrong specifically enough to act on. The eye-roll version is a modal confirming a no-op, or a toast saying something went wrong with no hint of what or why. - **Visual and interaction consistency** — The same kind of thing looks and behaves the same way across the product: buttons of equal weight share a style, primary actions sit predictably, spacing and typography follow a small number of rules rather than per-screen invention. Becomes possible to assess seriously only once acknowledgement and proportionality are in place; before that, consistency of silence is not a virtue. The bad version is each screen looking like a different person built it on a different day. - **Information hierarchy and density** — On any given screen, what the user is supposed to look at first is obvious, secondary detail recedes, and the page neither drowns the user in fields nor hides what they came for behind extra clicks. Practitioners argue about this constantly: too sparse feels like a prototype, too dense feels like a control panel, and the line between them is the difference between professional and amateur. Depends on visual consistency — hierarchy expressed through ad-hoc styling reads as noise rather than signal. - **Edge state completeness** — Empty states, loading states, partial-data states, permission-denied states, and error states are designed, not accidents. A first-run user with no data sees something deliberate; a slow network produces a real loading affordance, not a flash of broken layout; an error tells the user what to do next. This is where finished products separate from demos, and it is invisible until you actually hit the state — which is why teams routinely ship without it. - **Stakeholder-legible UX health** — A non-engineer (founder, support, PM, designer) can answer questions like which actions in the product currently complete without feedback, where users are most likely to feel lost, and whether the experience improved or regressed this month — without reading code or shoulder-surfing a developer. This is the capstone: it only becomes honest once the underlying surface is consistent enough to inventory and measure, and without it the other dimensions drift because no one outside engineering can tell when they slip.

## Ownership Zone Owns the coherence of the workspace as a multi-package monorepo: the root workspace declaration, the shape and conventions of packages under packagesprompts: logical-model usage, registry name@version uniqueness, zod input contracts, deterministic render, and eval coverage. ## Rubric - **Versioning discipline** — Prompt changes bump version; each name@version is unique in the registry; shipped versions are not silently edited in place. - **Model agnosticism** — Prompts reference logical model names (reasoning-mid, reasoning-high, fast-cheap) and never hardcode vendor model IDs. - **Typed input contract** — Every prompt declares a zod input schema and is rendered through validated input (renderSafe), failing fast on bad input. - **Render purity** — render() produces ChatMessage[] deterministically from validated input with no side effects or hidden state. - **Eval coverage** — Prompts carry eval cases asserting output shape/quality; high-value prompts are not shipped eval-less.

## Ownership Zone Owns the path a new user or contributor walks from a fresh clone to a running local instance with all integrations live. The territory covers the README and quickstart, the .env.example and every variable a real run depends on, the runbook for setting up the GitHub OAuth app and obtaining tokens for GitHub, CircleCI, and Anthropic, the Settings page copy that guides token entry in-product, the MCP server setup guide, and the version pins (Node, package manager) that determine whether install steps even work. Also owns the contract that these surfaces stay in sync with each other and with the actual configuration the code reads at runtime, so that setup instructions do not drift as dependencies and integration points change. ## Rubric - **Runtime-config truth** — The set of environment variables, secrets, and version pins documented for setup matches what the code actually reads and requires at startup, with nothing extra and nothing missing. This is the floor the rest of the rubric stands on: if the documented config is fiction, every other dimension is grading a tour that leads somewhere the code does not live. Excellence looks like a single source of truth that documentation derives from, not two lists drifting apart; the failure mode is a new user copying a .env that boots the server but silently disables a feature. - **First-run path is linear** — A new contributor follows one ordered path from clone to working app, with no branching choose-your-own-adventure between platforms, package managers, or optional integrations until the core path works. Sits on top of runtime-config truth: ordering steps only helps if the steps themselves are real. The bad version is a README that lists prerequisites, configuration, and commands as parallel sections and leaves the reader to sequence them. - **Third-party setup is walked, not waved at** — For every external account, OAuth app, or token the product depends on, the docs name where to click, what scopes or permissions to grant, what to paste where, and how to tell it worked. Only meaningful once the first-run path is linear; otherwise the third-party detour stalls a user mid-sequence with no way back. Excellence reads like a runbook a non-expert can execute; the eye-roll version is a sentence saying create a GitHub OAuth app and configure the callback URL with no link, no field names, and no example values. - **In-product guidance matches the docs** — Settings pages, empty states, and inline help for tokens and integrations agree with the external docs on names, formats, and where to obtain values, and they degrade gracefully when something is missing or wrong. This is a stakeholder-facing dimension: a user who never opens the README should still succeed, and a support conversation should not have to reconcile two different vocabularies for the same token. Bad implementations have a Settings field labeled one way and a README that calls the same thing something else. - **Failure modes are legible to the person hitting them** — When setup goes wrong — wrong Node version, missing env var, expired token, misconfigured OAuth callback — the error the user sees points at the surface they need to fix, not at a stack trace ten layers down. Becomes possible once runtime-config truth is in place: you can only diagnose a missing variable clearly if you know which variables are required. The failure mode is a generic 500 or a TypeError on undefined that sends the user to ask in chat instead of self-serving. - **Doc freshness has an owner and a trigger** — Onboarding surfaces are revisited on a known trigger — dependency bumps, new integrations, version pin changes, settings additions — rather than whenever someone happens to notice rot. This dimension is invisible from the codebase alone: it is about team practice, not file contents. Excellence is a contributor knowing that adding a new env var or integration is not done until the corresponding doc surfaces are updated; the bad version is README drift discovered six months later by a frustrated new hire. - **Time-to-first-success is known** — Someone owns the answer to how long it takes a new contributor to go from clone to a running app with real integrations, and that number is measured from real attempts rather than guessed. The capstone — only honest once the dimensions above hold, because otherwise the number is measuring confusion rather than setup. Stakeholders (maintainers, hiring managers, OSS contributors) can answer is onboarding getting better or worse without reading code; the failure mode is a team that believes setup takes 15 minutes because that is how long it takes them, while every newcomer quietly spends three hours.

## Ownership Zone Every user-facing input surface in the codebase — form fields, URL parameters, API request bodies, file uploads, and any data sourced from external systems — and the validation, escaping, and encoding logic that prevents malicious payloads from reaching execution contexts. This includes input validation at the boundary, output encoding for the rendering context (HTML, SQL, shell, JSON), and the relationship between declared input schemas and the actual sanitization applied downstream. The steward owns the gap between what a user can send and what the system safely executes. ## Rubric - **Boundary validation is declarative** — Input validation lives at the entry point and is expressed in a single source of truth — a schema, type definition, or validation rule that every handler consults. Without this, validation logic scatters across handlers and diverges; a field validated in one endpoint is trusted unvalidated in another, and the gap is invisible until exploit time. Validation is impossible to skip by accident. - **Output encoding matches the context** — Data is encoded for the specific context it enters — HTML entities for HTML, SQL escaping for queries, shell quoting for commands, JSON escaping for JSON. A single encoding function applied everywhere is a sign that the team does not distinguish contexts; the same string safe in HTML is dangerous in SQL. Encoding is applied at the point of output, not assumed to have happened upstream. - **Injection vectors are named and tested** — The team knows which inputs can reach which execution contexts and has written tests that verify each vector is blocked. Without this, injection risks hide in the gap between what the team thinks is validated and what actually is. A new feature that adds a path from user input to a database query is a typed change that surfaces the injection test, not an implicit assumption. - **Dangerous operations are explicit** — Code that interprets user input as code — eval, dynamic SQL construction, template injection, unsafe deserialization — is visible and rare. If the codebase uses these patterns, they are justified in comments, isolated to a small surface, and guarded by strict input constraints. A reader should be able to find every place user input flows into code execution in under a minute. - **Validation failures are observable** — When input validation fails, the event is logged with enough context to detect patterns — repeated failures from the same source, systematic probing of a field, or a new attack vector. A validation failure that disappears silently or is only visible in a debug log is a missed signal; the team should be able to answer whether they are under attack without reading code. - **Security assumptions are documented** — The team has written down what they assume about input — which fields are trusted, which are user-controlled, which sanitization is applied where, and what the consequences are if an assumption breaks. Without this, the next engineer assumes the wrong thing and introduces a gap. Documentation is updated when assumptions change, not written once and forgotten.

## Ownership Zone Every Content Security Policy directive served by the Next.js frontend — script-src, frame-src, connect-src, style-src, img-src, font-src, and the rest — along with each allowed origin, hash, or nonce, the feature or integration that justifies it, and the mechanism (middleware, headers config, meta tag) that delivers the policy to the browser. The zone covers how the policy is composed, how it is rolled out (report-only vs enforcing), how violations are observed, and how the policy stays aligned with the actual set of third parties the product depends on. It also covers the human-facing side: whether product, security, and integration owners can answer what is allowed, why, and what would break if it were removed. It does not own the third-party scripts themselves or the application code that uses them — only the trust boundary that decides what the browser is permitted to load and execute. ## Rubric - **Directive completeness and precision** — The floor the rest of the rubric stands on. Every fetch directive a modern app needs is explicitly set rather than inherited from default-src by accident, and each one lists the narrowest set of sources that actually make the feature work. The bad version is a single sprawling default-src with wildcards and a script-src that grew by accretion; the good version is a policy where you can point at any entry and name what would break without it. - **Provenance of every allowance** — Every origin, hash, and nonce in the policy traces back to a specific feature, vendor, or integration, recorded somewhere a human can read. Without this, the directive surface becomes a graveyard of entries no one dares delete; with it, removing a vendor is a normal cleanup task instead of a multi-hour archaeology dig. This is the dimension the directive inventory and justification-coverage metric exist to make reportable. - **Nonce and hash discipline over unsafe-inline** — Inline scripts and styles are admitted via per-request nonces or content hashes, not via blanket unsafe-inline or unsafe-eval escape hatches. The contrast: a policy that looks strict on paper but quietly carries unsafe-inline because one analytics snippet needed it three years ago is failing this dimension, even if every other directive is tight. - **Violation observability** — Only meaningful once the policy is precise enough to trust: a noisy policy produces noisy reports no one reads. CSP violation reports are collected, deduplicated, and routed somewhere a human actually looks, with enough context (directive, blocked URI, source file, user agent) to tell a real attack or regression apart from a browser extension. Silent enforcement with no report sink is the failure mode this calls out. - **Safe rollout and change discipline** — Becomes possible once observability is in place. New directives or tightened ones go through report-only before enforcement, changes are reviewed against the inventory rather than appended blindly, and there is a known path to ship a fix when a third party rotates a domain. The bad version is editing the policy directly in production and finding out from customer reports. - **Stakeholder legibility** — The capstone, and the dimension that fails most quietly. A non-engineer — a security reviewer, a vendor-onboarding PM, a compliance auditor — can answer what third parties the site trusts, why each is trusted, and what changed last quarter, without reading middleware source. If that question requires grepping the repo, the policy is technically correct but organizationally opaque.

## Ownership Zone Every PostHog integration point across the platform — SDK initialisation and provider wiring on the web surface, every capture, identify, and group call site, autocapture and session replay configuration, feature-flag usage, and the relationship between events emitted in code and what growth, product, and founders consume downstream in PostHog dashboards, funnels, and retention reports. The zone extends to instrumentation gaps in adjacent surfaces (such as CLI or server-side tooling) where product-critical flows happen outside the browser and represent blind spots in the user journey. It also covers the event taxonomy itself — the naming conventions, property shapes, and type-safety guarantees that determine whether data arriving in PostHog is queryable signal or accumulating noise. The steward owns the contract between the code that emits events and the humans who try to answer questions from them. ## Rubric - **Event taxonomy discipline** — Every event name follows a single documented convention and the convention is enforced at the call site, not by downstream cleanup or rename rules in the warehouse. The failure this guards against is the same logical moment shipped under three slightly different string literals from three components, producing three lines in PostHog where there should be one. This is the floor the rest of the rubric stands on: no other dimension is meaningful if the taxonomy is incoherent, because every funnel and dashboard sits on top of names. - **Type-safe emit boundary** — Tracking calls reference a shared, typed catalogue of event names and property shapes rather than passing ad-hoc string literals and untyped property bags. Without this a typo or a renamed property silently breaks a funnel and nobody notices until a quarterly review. Builds directly on taxonomy discipline — the catalogue is the taxonomy made enforceable, and the compiler becomes the first reviewer of every analytics change. - **Identify and group hygiene** — Identify fires at session-start and auth-state-change with a stable user ID, and group associates users with their org or tenant where applicable, before any meaningful event is captured in that session. Without this events land as anonymous noise and org-level analytics are fiction; funnels built on unidentified events silently undercount conversion. Sits alongside taxonomy discipline as a foundational concern — a clean name on an anonymous event is still a half-measurement. - **Coverage of meaningful moments** — Signup, activation, the handful of key product actions, upgrade, error states, and churn-risk moments all fire an event, and coverage is judged by whether a product or growth stakeholder can answer what happened in the user journey from PostHog alone without asking an engineer to query the database. The bad version is a dashboard full of pageviews and autocapture clicks with no domain verbs, where every real question requires a SQL detour. Only meaningful once the taxonomy is stable enough that adding a new event doesn't create ambiguity with existing ones. - **SDK configuration consistency** — PostHog is initialised once per surface with explicit, reviewed settings for autocapture, session replay, cross-subdomain tracking, PII redaction, and feature-flag bootstrap, and those settings agree across client and server and across environments. Configuration disagreements produce data that looks correct in staging and breaks in production, or worse, leaks PII that a privacy review assumed was redacted. Becomes auditable once identify hygiene is in place, because misconfigured init is invisible when users aren't identified. - **Dashboard-to-code alignment** — Every event referenced in a dashboard, funnel, or insight corresponds to a live capture call, and every capture call is consumed by at least one downstream artefact a stakeholder actually looks at. Orphaned dashboard references produce silent zeros that erode trust in the analytics surface; orphaned capture calls waste payload and clutter the event stream so newcomers can't tell signal from legacy. This is a capstone dimension — only meaningful once the taxonomy, type safety, and coverage dimensions are healthy enough that the catalogue of events is stable and enumerable on both sides. - **Analytics health legibility** — A non-engineer can answer are events still flowing and did we lose tracking last week without paging someone, because ingestion volume, event-type cardinality, and identify-rate are monitored or at least reviewed on a known cadence. The bad version is discovering a three-week instrumentation outage when a board deck is being prepared. Sits on top of every other dimension: you can only monitor what you've named, typed, identified, and wired to something a stakeholder reads.

## Ownership Zone Owns the resilience of the Next.js and React framework surface across upgrades — the pinned versions of next, react, react-dom, and eslint-config-next; the App Router conventions (segment filenames, route groups, layouts, server vs client component boundaries); the build and lint gates that catch framework-level regressions before deploy; and the backlog of known framework risks that need to be worked down. Also owns the relationship between the codebase and Vercel's deployment expectations, so that what builds locally builds on Vercel and what renders in dev renders in production. The zone covers everything that determines whether a framework or runtime bump is a routine chore or a silent outage. ## Rubric - **Version pinning discipline** — Framework-critical packages (next, react, react-dom, the matching eslint config) are pinned to exact versions, not caret or tilde ranges. This is the floor the rest of the rubric stands on: until the versions installed in CI, on a fresh clone, and on Vercel are provably identical, every other dimension is grading a moving target. The bad version of this dimension is a lockfile that drifts between environments and an upgrade that lands by accident on a Tuesday afternoon. - **Pre-deploy build gating** — A production build (and the framework's own type and lint passes) runs on every push and PR and blocks merge on failure. Only meaningful once versions are pinned — otherwise the gate is checking a different build than the one that ships. The failure mode this dimension calls out is discovering a broken build from the deploy log instead of from CI; excellence means the first place a framework regression surfaces is a red check, not a white screen. - **Routing and component-boundary correctness** — App Router conventions are followed strictly: canonical segment filenames, deliberate placement of server vs client components, no accidental client-bundling of server-only code. Sits on top of the build gate, because lint and type rules are the mechanism that makes these conventions enforceable rather than tribal. The bad version is a file named almost-but-not-quite right that silently fails to route, or a use client added to silence an error without understanding what crossed the boundary. - **Upgrade rehearsal and risk backlog** — The team treats framework upgrades as a rehearsed activity, not an emergency: known framework risks, deprecations, and migration steps live in a tracked backlog with priorities, and majors are taken on a deliberate cadence with a known rollback. Becomes possible once the prior dimensions exist, because rehearsal is only credible when versions are pinned and CI catches regressions. Excellence here is a reader being able to answer what's the next framework risk we owe time to without asking a person. - **Deployment-target fidelity** — The local and CI build environment matches what Vercel (or the equivalent target) actually runs: Node version, build command, environment variables, edge vs node runtime choices, and image/route configuration. The bad version is the works on my machine class of incident where the production runtime quietly disagrees with the dev runtime about a server component, a route handler, or a cached fetch. - **Stakeholder-legible upgrade posture** — A non-engineer stakeholder (PM, founder, ops) can answer are we current, are we exposed, and what would an upgrade cost without paging an engineer to read package.json. This is the capstone — only honest once pinning, gating, conventions, and the risk backlog are in place, because otherwise the answer is a guess dressed up as a status. Excellence is a posture that can be reported on, not folklore held in one engineer's head.

## Ownership Zone Adherence to the industrial/brutalist design system: color tokens, typography contracts, component variant usage, layout patterns, and zero-radius enforcement across the Next.js app. ## Rubric - **Token discipline** — Components use defined color tokens (primary, surface, surface_two, text-primary, text-muted, error, warning, success) and their documented scale steps. No ad-hoc hex values, no non-existent tokens like brand.400, no whiteAlpha borders. - **Typography contract** — Space Grotesk for headings/body/buttons, JetBrains Mono for labels/data/code. Text styles (monoLabel, monoBody, monoSmall) are used for their documented purposes. Uppercase + wide tracking signals system text, not human-readable content. - **Variant usage** — Buttons use industrialPrimary, industrialOutline, or industrialCta — never bare Chakra solid/outline. Inputs use the theme variant without inline bg/borderColor/_hover/_focus overrides. Tables use variant bordered. Components use AppModal, Card, DataTable wrappers rather than raw Chakra primitives. - **Surface and border hygiene** — Surfaces are delineated by surface_two.500 borders, never drop shadows. No border-radius anywhere — the theme overrides all radii to 0. No CircularProgress or rounded elements that contradict the zero-radius constraint. - **Layout pattern conformance** — Landing pages use the 1440px container with border rails and section dividers. Blog/content headers use the 7fr/5fr grid with yellow breadcrumb label pattern. Auth pages use centered VStack with hyperspace animation. App pages use Layout with sidebar at 240px.

## Ownership Zone Correctness and completeness of marketing blog post PRs in the Next.js app: the post page file under packages/app/src/pages/blog/ (named for the post slug), its BLOG_POSTS metadata registration, hero and card image wiring, SEO and structured data, sitemap inclusion, and conformance to the blog component system, so a correctly-built post can be approved, merged, and deployed without manual review. ## Rubric - **Post registration integrity** — Every new post has both a page file under packages/app/src/pages/blog/ named for its slug and a matching entry in BLOG_POSTS (consts/blogPosts.ts). The slug is unique, kebab-case, and consistent across the filename, the metadata.slug field, and the page's metadata lookup; the default export is the PascalCase form of the slug. No orphaned page without a registry entry, and no registry entry without a page. - **Metadata completeness & correctness** — The BlogMetadata entry has all required fields well-formed: title, description, ISO date (YYYY-MM-DD), tag, h1, readTime, a cardImage URL, and an author key that exists in BLOG_AUTHORS. The page reads every displayed value from the metadata constant rather than hardcoding titles, dates, or image URLs in JSX. - **Hero image & asset wiring** — cardImage points to the Supabase assets/blog bucket URL for the post slug, is webp, and the referenced asset was actually uploaded (not a placeholder or dead link). The image is wired through BlogHeroImage and SEOHead ogImage, and its aspect ratio is reasonable for OG cards (about 1.91 to 1). - **SEO, structured data & sitemap fidelity** — SEOHead is wired with the canonical URL via canonicalUrl(BLOG_ARTICLE(slug)), the standard 'Title | HyperServe Blog' title format, the cardImage as ogImage, and jsonLd from buildBlogPostingJsonLd(metadata). Open Graph, Twitter card, canonical, and BlogPosting JSON-LD are present and reference the real post; trackPageView fires for the article. The post is reachable from sitemap.xml.tsx, which derives blog URLs and lastmod from BLOG_POSTS via getAllBlogMetadata, so the registry entry and its ISO date must be valid for the post to be indexed. - **Component & markup conformance** — The post uses only the approved blog components in the canonical structure (BlogLayout wrapping BlogHeader, BlogTLDR, BlogHeroImage, BlogSection and BlogHeading content, BlogCTA, then RelatedPosts) rather than raw Chakra or ad-hoc markup. JSX quotes and apostrophes are escaped as HTML entities, and component props match their documented contracts. - **Build & link safety** — The PR typechecks (no TS errors), removes unused imports (e.g. Link when there are no internal links), and is scoped to the expected files without stray changes. Internal blog links resolve only to slugs that already exist in BLOG_POSTS, with no dead references.

## Ownership Zone WCAG 2.1 AA accessibility of the SvelteKit dashboard: keeping the pnpm a11y:auth regression gate green and correctly extended as new surfaces ship, semantic/ARIA and keyboard correctness across authenticated and public surfaces, color-contrast token discipline, status/error messaging, and the compliance audit trail under compliance/accessibility/. ## Rubric - **Gate coverage integrity** — New authenticated routes, modals, dropdowns, and popovers are registered in PROFILES/subSurfaces (a11y-auth.mjs) with locale-stable selectors (data-testid/aria-*), so the delta-only a11y:auth ratchet actually scans them instead of silently missing coverage. - **Semantic structure & ARIA** — Headings, landmarks, lists, labels, roles, and ARIA attributes expose intent to assistive tech and respect the role allowlist — guarding the axe rule families that have fired here (label, dlitem, nested-interactive, select-name, aria-input-field-name, aria-prohibited-attr). - **Keyboard & focus management** — Every interactive control is reachable and operable without a pointer; route changes, dialogs, and async panels move or restore focus predictably; scrollable regions are focusable. Covers the non-automatable WCAG criteria axe cannot catch. - **Contrast & non-text affordances** — Text meets 4.5:1 and focus rings / essential non-text content meet 3:1 in BOTH light and dark mode, expressed through semantic color tokens rather than raw primitives (per contrast-audit.mjs gating policy). - **Status & error messaging** — Asynchronous changes, validation errors, and toasts announce via aria-live / role=status / role=alert appropriately (WCAG 4.1.3) — info/success/warning use the polite status convention, only true errors use alert. - **Compliance trail currency** — statement.md, roadmap.md, audit-log.md, and the contrast report stay in sync with shipped work and the WCAG 2.1 AA / SGQRI 008-2.0 target, and governance gaps (réaudit cadence, public statement, VPAT) stay visibly tracked.

## Ownership Zone I own accessibility quality for the React component layer in the client/ directory — every interactive surface a user can see, hear, focus, or be trapped inside. That spans modal dialogs and their focus management, the conversation UI and its live-updating message stream, the onboarding flow with its audio and form interactions, and the shared primitives (buttons, badges, inputs, toasts) that compose all of the above. I am responsible for semantic HTML and ARIA correctness, keyboard reachability and focus order, color contrast under the active theme, screen reader behavior including live regions and route-change announcements, and the automated regression coverage that keeps these properties from rotting between releases. I am also responsible for the legibility of accessibility status to non-engineering stakeholders — whether someone outside the team can answer what conformance level we ship at and what is currently blocking it. ## Rubric - **Semantic foundation** — Interactive elements use the native control that already encodes role, state, and keyboard behavior; ARIA is reached for only when no semantic element fits. This is the floor the rest of the rubric stands on — a div masquerading as a button invalidates every downstream claim about keyboard support, focus, or screen reader behavior, because the assistive tech never knew there was a control there to begin with. The bad version is a tree of clickable divs with onClick handlers and bolted-on role attributes; the good version is boring HTML that mostly just works. - **Keyboard and focus discipline** — Only meaningful once the semantic foundation is in place: every interactive element is reachable and operable by keyboard, focus order matches visual order, focus is visibly indicated, and focus is trapped and restored correctly across modals, drawers, and route changes. The failure mode to watch for is the keyboard user who tabs into a modal and cannot escape, or who dismisses one and is dropped at the top of the document with no idea where they were. - **Screen reader truthfulness** — Sits on top of semantics and focus: what a sighted user perceives and what a screen reader announces are the same story, told in the same order. Dynamic content (streaming messages, toasts, validation errors, route changes) is announced through appropriate live regions or title updates rather than appearing silently; decorative content is hidden from the accessibility tree rather than narrated as noise. The bad version is a chat UI where new messages render visually but the screen reader stays silent, or where every icon is read aloud as image image image. - **Perceptual robustness** — Color contrast meets WCAG AA across both text and non-text UI under every supported theme, information is never conveyed by color alone, and the UI remains usable at 200% zoom and at the platform's reduced-motion and high-contrast settings. This dimension is what catches the regressions a theme rollout or a designer's palette tweak quietly introduces, where the pixels look fine to the person shipping them and unreadable to someone with low vision. - **Regression coverage** — Becomes possible only once the dimensions above have a defined good state worth defending: automated checks (axe-style audits, focus and keyboard tests, contrast tests) run in CI on the surfaces that matter, fail loudly on regression, and are wired into the same PR gate as the rest of the test suite. The bad version is a one-time audit spreadsheet; the good version is that an accidental aria-label removal or a contrast-breaking color change cannot land without someone explicitly overriding a red check. - **Conformance legibility** — The capstone — only honest once the underlying surface is consistent enough to measure. A non-engineering stakeholder (PM, founder, support, legal) can answer what conformance level the product ships at, what the current blocking violations are, and when they will be resolved, without reading code or paging an engineer. The failure mode is an a11y posture that exists only in individual engineers' heads and surfaces only when a customer or auditor asks an uncomfortable question. - **Triage and severity discipline** — Accessibility findings are classified by impact and WCAG level, not by whoever shouted loudest; Level A blockers are treated as release-blocking, AA issues are scheduled, and moot findings are explicitly closed with reasoning rather than left to drift. This is what separates a team that has an accessibility practice from a team that has an accessibility backlog — the latter accumulates findings indefinitely because nothing distinguishes a screen-reader-broken flow from a nice-to-have aria-describedby.

## Ownership Zone Owns the contract surface between the standalone MCP server process and the main web application that shares its data and operations. This includes the tool definitions exposed by the MCP server, the prompt templates that shape how those tools are described to LLM clients, the HTTP endpoints the web app exposes for MCP-mediated traffic, and the shared understanding of PR data shapes and available operations that both sides depend on. The zone covers how schemas, tool catalogs, and prompts evolve over time without the two processes silently drifting, and how MCP clients (and the humans configuring them) learn what tools exist and what they do. ## Rubric - **Single source of truth for shared shapes** — PR data shapes, tool argument schemas, and operation contracts are defined once and consumed by both the MCP server and the web app, rather than re-declared on each side and kept in sync by hope. This is the floor the rest of the rubric stands on: until both processes are reading from the same definitions, every other dimension is grading two artifacts that may already disagree. The bad version is parallel TypeScript types or hand-written JSON schemas that look similar at a glance and diverge field-by-field over months. - **Tool catalog discipline** — Only meaningful once shared shapes are in place: each MCP tool has a clearly named purpose, non-overlapping responsibility with its neighbors, typed arguments, and a declared result shape. Tools fail loudly with structured errors rather than returning success with an empty payload, and deprecated tools are removed or explicitly marked rather than left to rot in the catalog confusing clients. - **Prompt and description fidelity** — Tool descriptions and prompt templates accurately reflect what the tools actually do, including their argument semantics, side effects, and limits. The bad version is a description written when the tool was first added that no longer matches its behavior, leaving LLM clients to call tools based on a fictional contract; the good version has descriptions that change when behavior changes, treated as part of the contract rather than docstring decoration. - **Versioning and evolution discipline** — Becomes possible once the catalog and shared shapes are stable enough to reason about: changes to tool signatures, prompt templates, or response shapes are made with awareness of who is on the other end of the wire. Breaking changes are visible as breaking, additive changes are genuinely additive, and the team has an answer to *what happens to a client pinned to last month's contract* that isn't a shrug. - **Cross-process integration testing** — The contract is exercised end-to-end, not just unit-tested on each side independently. A test that boots both surfaces and walks through representative tool calls catches the divergence that two passing test suites on either side will miss; without this, the first signal that the contract broke is an LLM producing nonsense in production. - **Client-facing legibility** — The capstone, only honest once the dimensions above hold: a non-engineer integrating an MCP client (an analyst configuring Claude Desktop, a PM wiring up an agent) can answer *what tools does this server expose, what do they do, and what do I pass them* from the server's own self-description, without reading source. If the answer requires pinging an engineer or reading the implementation, the contract is leaking out of the artifact that's supposed to carry it.

## Ownership Zone Owns the Astro static site build pipeline end-to-end: the integrity of every `astro build` run, the warnings and errors it surfaces, the wall-clock time it takes, and the health of the inputs the build consumes (component imports, frontmatter contracts, image references, route collisions, layout integrity). Covers the relationship between source content and built output across the full file tree, the CI signal that gates deploys on a clean build, and the visibility of build health to non-engineering contributors who edit content but do not read build logs. Does not own runtime behavior in the browser or content authorship itself — only whether what authors and developers commit produces a trustworthy, fast, warning-free build artifact. ## Rubric - **Build determinism** — The same commit produces the same build output, the same warning set, and roughly the same duration on every run. This is the floor the rest of the rubric stands on: until the build is deterministic, every other dimension is grading noise. Flaky failures, order-dependent warnings, and "it built last time" are the failure modes this dimension calls out. - **Warning hygiene** — Warnings are treated as signal, not wallpaper. A clean build means zero warnings on main, every warning that does appear has a known owner and a known fate (fix, suppress with reason, or upstream issue), and new warnings fail loudly in CI rather than accumulating into background noise nobody reads. The bad version: a build log with 40 warnings everyone scrolls past. - **Input contract enforcement** — Only meaningful once the build runs cleanly: the things the build consumes — component props, frontmatter schemas, image paths, collection entries, route definitions — are validated at build time against a declared contract, so a typo in a content file or a renamed component fails the build with a precise message rather than producing a silently broken page. Contracts are explicit and versioned, not implicit in whatever the templates happened to read last. - **Build performance budget** — Builds complete within a stated time budget appropriate to the site's size, and sustained drift against that budget is treated as a regression with an owner. Sits on top of determinism: you can only defend a budget when run-to-run variance is small. The bad version is a build that quietly grew from 30 seconds to 4 minutes over a year because nobody was watching the trend. - **Content-author feedback loop** — Becomes possible once input contracts and warning hygiene are in place: a non-engineer who edits a markdown file or swaps an image gets a clear, local signal about whether their change will build, in language they understand, before it reaches main. Excellence here is judged by whether content contributors can self-serve — not by how elegant the build internals are. The failure mode is a content editor whose PR breaks the build and who cannot tell why without pinging an engineer. - **Deploy gate trust** — The capstone — only honest once the dimensions above hold: a green build on main is treated as sufficient evidence to deploy, and a red build actually blocks. No one routinely overrides the gate, no one ships from a local build to dodge CI, and stakeholders trust that "the site builds" means the site is in fact deployable. When the gate has been bypassed, there is a recorded reason and a follow-up.

## Ownership Zone Version, identity, MCP server name, skill slug, and install-instruction consistency across the marketplace manifest, plugin manifest, SETUP.md, and README for the Steward Claude Code plugin. ## Rubric - **Version synchronization** — Marketplace version, plugin version, and any version references in SETUP/README move together on every release; no stale version strings linger after a bump. - **Identity and naming consistency** — Plugin name, MCP server name, marketplace name, and brand references match across manifest, SETUP, README, and skill files; old names (e.g. contextgraph) do not leak back in after a rename. - **Skill registration parity** — Every shipped skill under plugins/steward/skills/ is reflected with its real slug (e.g. steward:define-steward) in README and SETUP verification steps, and removed skills are removed from docs. - **Install and verify instructions** — Documented install, reload, update, /mcp check, and skill-availability check match what the current marketplace and plugin manifests actually expose; commands users are told to run still work. - **MCP server contract surface** — The mcpServers.steward declaration in plugin.json (name, type, url) matches what skills and docs tell users to expect, and changes to the server name or transport are propagated through every artifact.

## Ownership Zone Every image asset the site depends on — food item photos, guide illustrations, and the OG image generation pipeline — together with the references that bind them to content entries, components, and route templates. This covers the full lifecycle: which images exist on disk, which are referenced, which are generated on demand, whether each rendered page resolves to a real file, and whether the social-sharing surface produces valid output for every route. The zone includes the inverse direction too: assets that exist but are no longer referenced, and references that point at paths nothing produces. It does not extend to image content choices or visual design — only to whether the pipeline from authored reference to delivered pixels is intact, lean, and observable. ## Rubric - **Reference resolvability** — Every image path named in content, components, or templates resolves to a real, non-empty file at build time, and an unresolvable reference fails the build loudly rather than shipping a broken `<img>` tag to production. This is the floor the rest of the rubric stands on: until references resolve, sizing, generation, and orphan hygiene are all grading work that may render as a broken icon anyway. - **Generated-image pipeline integrity** — Routes that rely on generated imagery (OG cards, derived thumbnails, templated illustrations) produce valid, correctly-dimensioned output for every input the route can receive, not just the handful exercised during development. The bad version of this dimension is a generator that silently emits a 0-byte file or a fallback placeholder for half the catalogue and nobody notices until a link is shared. - **Asset library hygiene** — The set of files on disk stays close to the set of files actually referenced; orphans are pruned on a known cadence rather than accumulating as repo weight, and additions are deliberate rather than drive-by. Only meaningful once reference resolvability is in place — otherwise pruning is dangerous because you cannot trust the reference graph you are pruning against. - **Delivery weight discipline** — Images are sized, compressed, and formatted for the surface that actually consumes them, with the source-of-truth original kept separate from the web-delivery variant. A rubric-failing setup ships 4MB hero JPEGs to mobile, has no convention for which dimensions and formats are canonical, and treats every new image as a one-off decision. - **Authoring ergonomics** — Sits on top of the dimensions above: a content author can add a new food item or guide without learning the asset pipeline, knows exactly where to drop the image and how to reference it, and gets immediate feedback when they get it wrong. When this fails, you see the same handful of engineers re-explaining the conventions in PR review and authors avoiding image-heavy entries entirely. - **Stakeholder-facing visibility** — The capstone — only becomes possible once the surface is consistent enough to measure honestly. A non-engineer (content owner, founder, marketer checking a social share) can answer questions like how many pages have working previews, which entries are missing imagery, and whether last week's content drop rendered cleanly, without asking an engineer to grep the repo.

## Ownership Zone Owns the GitHub OAuth flow end-to-end — login initiation, callback handling, session establishment, and logout — and the full lifecycle of every httpOnly cookie token stored on behalf of the user (GitHub, CircleCI, Anthropic, and any future provider tokens that ride the same cookie surface). Responsible for how token expiry, revocation, corruption, and CSRF-class attacks are detected and surfaced, so that a stale or hostile credential fails cleanly at the auth boundary rather than cascading into downstream API routes. Guards the contract between edge-runtime auth routes and server-side proxying routes: which routes are allowed to assume a valid session, how that assumption is validated, and what happens when it does not hold. Also owns the operator-facing visibility into auth health — who is logged in, why logins fail, and which routes are protected — so that session-layer incidents are diagnosable without grepping the codebase. ## Rubric - **Cookie hygiene as the foundation** — Every token cookie is httpOnly, scoped, signed/encrypted as appropriate, and has a single owner that knows its set, read, and clear paths. This is the floor the rest of the rubric stands on: until cookie semantics are unambiguous, every other dimension is reasoning about state that other code paths can quietly mutate. The bad version is tokens written in one place and forgotten in another, where logout leaves residue and nobody can say which routes touch which cookie. - **CSRF and callback integrity** — The OAuth callback verifies that the response it is processing is the one this browser initiated: state parameter generated, stored, and checked; redirect targets constrained to a known set; replayed or cross-origin callbacks rejected loudly. Builds directly on cookie hygiene, since state itself rides the cookie surface. The failure mode this dimension exists to prevent is a callback that happily mints a session for whoever shows up with a valid-looking code. - **Failure-mode behavior under bad credentials** — Expired, revoked, malformed, and impersonated tokens produce a single well-defined outcome at the auth boundary: the session is invalidated, the user is sent through re-auth, and downstream handlers never see a half-valid credential. Only meaningful once cookie hygiene and callback integrity are in place; otherwise the system cannot tell a bad token from a missing one. The bad version is a 500 from a deep API call because a GitHub token silently expired three days ago. - **Route auth contract clarity** — Every server route falls into a known category — public, session-required, session-optional, internal — and the category is enforced in one obvious place rather than re-derived per handler. This sits on top of failure-mode behavior: a route only benefits from a clean failure path if it actually invokes the validator. The bad version is the auth check copy-pasted into some handlers, forgotten in others, and impossible to audit without reading every file. - **Stakeholder visibility into auth health** — Non-engineering stakeholders (support, ops, the person triaging a Monday-morning incident) can answer questions like did logins start failing last Thursday, is this user actually authenticated, and which provider token is stale — without paging an engineer to read logs. This dimension is not visible from the codebase alone; it is judged by whether the people downstream of the auth boundary can self-serve. Becomes possible only once the route contract and failure modes are consistent enough to measure honestly. - **Cross-provider token coherence** — When more than one provider's token rides the same session, their lifecycles are reasoned about together: a revoked GitHub token does not leave a live CircleCI cookie behind, and adding a new provider follows a known pattern rather than inventing a fourth cookie shape. This is partly an organizational property — it depends on whoever adds the next provider knowing the pattern exists — and partly a code property. The bad version is each provider integration looking like it was written by someone who had never seen the others. - **Auditability of session decisions** — Every session-affecting decision (issued, refreshed, rejected, cleared) leaves a trace that an operator can reconstruct after the fact, with enough context to distinguish user error from attack from bug. The capstone dimension: only meaningful once the decisions themselves are consistent across cookies, callbacks, failure modes, and routes. The bad version is a user reporting they were logged out and nobody, including the steward, being able to say why.

## Ownership Zone Subscription lifecycle state machines, usage metering, free-tier enforcement, Stripe billing integration, and API access gating. ## Rubric - **State machine integrity** — Subscription status transitions (free_tier_active → grace_period → exceeded; active → past_due → unpaid → canceled) match the intended lifecycle, leave no orphan states, and trigger the correct side effects (content lock/unlock, emails, analytics). - **Usage metering accuracy** — CloudFront log parsing, bandwidth aggregation, storage tracking, and Stripe metered billing event submission faithfully reflect real consumption without double-counting or data loss. - **Free tier enforcement** — Limits (video count, file size, bandwidth), grace period timing, alert email thresholds, and content locking/unlocking apply consistently and at the correct thresholds defined in subscription constants. - **Access gating consistency** — SubscriptionGuard, plan checks, skipSubscriptionGuard decorators, and demo user exceptions enforce the correct access boundary for every API route without gaps or false blocks. - **Stripe webhook fidelity** — Incoming Stripe subscription and checkout events map to the correct internal state changes without gaps, silent failures, or status/plan mismatches between Stripe and the subscriptions table.

## Ownership Zone Friction and legibility of moving a backlog item from queued to merged in production, across the MCP server, the CLI, and the plugin: the lifecycle state machine and its truthful linkage to PRs and branches, the MCP and notification surface that tells agents and humans what to do next, and the trust signals that let a workspace widen backlog autonomy over time. Excludes PR-review verdict quality (owned by PR Thread Responsiveness and review-policy) and CI correctness. ## Rubric - **Lifecycle state truth** — A backlog item's state (queued / in_progress / proposed / done / dismissed) and its PR or branch linkage always reflect reality. Orphaned claims, expired-lease ghosts, items stuck after their PR merged or closed, and false orphaned-PR warnings are defects. - **Deliverable and contract legibility** — peek / claim / list responses expose what an agent needs to act correctly: the intended deliverable (pull_request vs note), the recommended next action, and lifecycle copy that does not push a PR onto note-shaped or already-done work. - **Progress visibility** — In-flight work is countable and surfaced. queued, in_progress, proposed, and awaiting-merge are distinguishable in counts and responses, and a claimed-but-PR-less item, a green-but-idle PR, or a done-but-unmerged item never sits invisibly. - **Delivery handoffs** — At each gate where a human must act — PR ready to review, ready to merge, conflicted, CI red, or a workspace stuck with un-executed backlog — the user is notified promptly and clearly with the correct next action. - **Selection continuity** — The path from signal to work stays coherent: consult's top-concern set and the queue's top item do not silently diverge, so the agent acts on what the stewards actually flagged rather than drifting to a different item. - **Autonomy trajectory** — The workspace's chosen autonomy level (merge-block threshold, auto-flow eligibility) is respected and legible, and the clean delivery history needed to justify widening autonomy over time is visible rather than hidden.

## Ownership Zone The architecture, configuration, and enforcement of data boundaries between independent tenants across the platform. This includes tenant identification and routing at the request boundary, schema-level isolation mechanisms, query filtering and access control, credential and secret scoping per tenant, and the visibility of isolation health to non-engineers through audit trails and breach detection. The steward owns the floor that prevents one tenant from reading, writing, or inferring the state of another. ## Rubric - **Tenant identity at the edge** — Every request carries a verified tenant identifier before any business logic executes. This is the floor the rest of the rubric stands on: until tenant identity is established and immutable at the boundary, downstream isolation is fiction. Tenant context is extracted from a single source of truth (JWT claim, session, header) and cannot be overridden by request parameters or inferred from data shape. - **Query-level filtering enforcement** — All data queries automatically scope to the request tenant without relying on caller discipline. Queries fail closed rather than silently returning cross-tenant data when a filter is missing. This sits on top of verified tenant identity: only meaningful once you know which tenant made the request. - **Credential and secret isolation** — API keys, database credentials, third-party tokens, and encryption keys are scoped per tenant and cannot be accessed by other tenants. A compromised credential in one tenant does not grant access to another tenant's resources or secrets. - **Schema-level boundaries** — The data model itself enforces tenant ownership: foreign keys, row-level security policies, or partition keys make it structurally impossible to query across tenant boundaries. A schema change that removes a tenant column or constraint surfaces immediately as a breaking change, not as a latent vulnerability. - **Isolation testing and validation** — Automated tests verify that queries with one tenant's credentials cannot read, write, or infer the existence of another tenant's data. Tests cover both happy-path isolation and edge cases like concurrent requests, batch operations, and error states. Isolation is not assumed; it is measured. - **Audit and breach visibility** — Cross-tenant access attempts, credential misuse, and isolation violations are logged and surfaced to non-engineers without requiring code review. A support team member or operator can answer whether a tenant's data was accessed by another tenant without paging an engineer, and breach detection runs on a known cadence.

## Ownership Zone Owns the surface that a newcomer hits in their first hour with the project: the README and any top-level docs that describe what the project is, the setup and run instructions, the prerequisites and toolchain expectations, the workspace and directory orientation, and the contributor guidance for making a first change. Responsible for keeping the stated identity of the project (name, purpose, domain, audience) aligned with what the code actually is, and for keeping installation, build, and run paths walkable from a clean machine. Covers the handoff from stakeholders and casual readers (what is this?) through to first-time contributors (how do I run it and where do I edit?). Does not own deep architectural docs, API references, or runtime operational guides — only the on-ramp. ## Rubric - **Truthful project identity** — The floor the rest of the rubric stands on: if the README describes a different project than the one in the repo, every other dimension is grading instructions to the wrong place. The stated name, purpose, domain, and tech stack match what a reader would conclude after ten minutes in the source tree, and template/scaffold residue from the project's origin has been replaced rather than left as quiet lies. - **Walkable setup path** — Only meaningful once identity is truthful, because setup steps for the wrong project waste the newcomer's trust before they hit a real error. A reader on a clean machine can go from clone to running app by following the documented steps in order, prerequisites are named with versions where versions matter, and the steps actually executed by the maintainer match the steps the doc tells a stranger to run. - **Orientation to the shape of the repo** — Sits on top of truthful identity: a newcomer who knows what the project is still needs to know where things live before they can contribute. The doc names the major directories, the workspace or monorepo layout if any, and where a first change is likely to go — so a contributor doesn't have to reverse-engineer the structure or guess which folder owns which concern. - **First contribution on-ramp** — Becomes possible once setup and orientation are in place. Conventions a contributor will trip over (formatting, commit style, branch flow, how to run tests or checks locally) are stated where a contributor will actually look, and the gap between running the app and submitting a change is short and explicit rather than tribal. - **Stakeholder legibility** — A non-engineer landing on the repo — a collaborator, a domain stakeholder, a curious visitor — can answer what is this, who is it for, and is it alive without reading code or asking the maintainer. The README opens with the answer to those questions rather than burying them under build badges and install commands, and the project's audience is named, not assumed. - **Drift resistance** — The capstone that keeps every dimension above honest over time: docs that were correct at one commit silently rot as the code moves. Onboarding content has a known owner and a known cadence for re-walking the path from scratch, changes that invalidate setup instructions are caught close to when they happen rather than discovered by the next newcomer, and the gap between code reality and documented reality is treated as a real defect rather than a cosmetic one.

## Ownership Zone Inngest step-function correctness across lib/inngest/workflows/: step boundaries, replay-safe state flow, idempotent side effects, and early-return ordering — ensuring every workflow produces correct results on both the initial run and any subsequent retry or replay. ## Rubric - **Step-return state flow** — State that must survive across steps is returned from step.run and captured in outer scope, never written by mutating a closure-captured variable. On replay, memoized step results are substituted without re-executing the callback, so mutations silently disappear; the steward flags any `let x = ...; step.run(..., () => x = ...)` pattern where x is read in a later step. - **Step boundary granularity** — Per-entity work (per-steward, per-concern, per-PR comment) is split into idempotent per-entity step.run blocks rather than bundled into one multi-side-effect step. Bundled steps cannot partial-retry, so one transient failure re-executes all side effects on replay or skips them all on memoized return. - **Idempotency of side effects** — GitHub API calls, check-run posts, PR comments, DB writes, and PostHog captures inside step.run are either safe to re-execute on retry or guarded by a deterministic key (SHA, comment marker, idempotency token). Replays and retries must not produce duplicate comments, double-counted events, or conflicting check runs. - **Early-return and failure-path ordering** — Detection and dispatch logic (PR-merge detection, scope filtering, installation health, debounce) runs before early-return branches, and failure telemetry covers early-error exits — not just the happy path. The steward flags happy-path-only instrumentation and skip-paths that swallow signals the user expects to see. - **Same-SHA persisted state reuse** — Persisted state read across steps (review verdicts, slot acquisitions, debounce gates, claim linkage) is correctly scoped to the head SHA and replay-safe. Stale persisted state from a prior head must not be reused on a new SHA, and a same-SHA acquire-miss must not silently carry forward a verdict that no longer reflects the diff.

## Ownership Zone Every moment where a person interacts with the application and forms a judgment about whether it feels professional, responsive, and trustworthy. This covers the full surface of user-triggerable actions and their feedback (toasts, confirmations, loading states, status changes, error surfaces), the visual and interaction language across screens (layout consistency, density, typography, affordances), the navigational and informational scaffolding that lets a user orient themselves, and the empty/error/edge states that decide whether the product feels finished or half-built. The steward owns the experiential contract end-to-end: from the instant a click happens to the moment the user is sure something happened, and from first impression of a screen to the user's confidence that they know what to do next. ## Rubric - **Action acknowledgement** — Every user-triggered action produces a visible, timely signal that the system received it and is acting on it: a loading indicator, a toast, a status change, or a confirmation. This is the floor the rest of the rubric stands on — without it, the user is guessing whether the product is broken, and judgments about polish, hierarchy, or stakeholder visibility are grading a surface the user has already lost trust in. The failure mode is the silent click: the action fired, the state changed somewhere, and the user has no idea. - **Feedback proportionality** — Sits directly on top of action acknowledgement: once feedback exists, the question is whether it matches the weight of the action. Trivial actions get lightweight signals, destructive or irreversible actions get explicit confirmation, long-running actions show progress rather than a frozen button, and errors surface what went wrong specifically enough to act on. The eye-roll version is a modal confirming a no-op, or a toast saying something went wrong with no hint of what or why. - **Visual and interaction consistency** — The same kind of thing looks and behaves the same way across the product: buttons of equal weight share a style, primary actions sit predictably, spacing and typography follow a small number of rules rather than per-screen invention. Becomes possible to assess seriously only once acknowledgement and proportionality are in place; before that, consistency of silence is not a virtue. The bad version is each screen looking like a different person built it on a different day. - **Information hierarchy and density** — On any given screen, what the user is supposed to look at first is obvious, secondary detail recedes, and the page neither drowns the user in fields nor hides what they came for behind extra clicks. Practitioners argue about this constantly: too sparse feels like a prototype, too dense feels like a control panel, and the line between them is the difference between professional and amateur. Depends on visual consistency — hierarchy expressed through ad-hoc styling reads as noise rather than signal. - **Edge state completeness** — Empty states, loading states, partial-data states, permission-denied states, and error states are designed, not accidents. A first-run user with no data sees something deliberate; a slow network produces a real loading affordance, not a flash of broken layout; an error tells the user what to do next. This is where finished products separate from demos, and it is invisible until you actually hit the state — which is why teams routinely ship without it. - **Stakeholder-legible UX health** — A non-engineer (founder, support, PM, designer) can answer questions like which actions in the product currently complete without feedback, where users are most likely to feel lost, and whether the experience improved or regressed this month — without reading code or shoulder-surfing a developer. This is the capstone: it only becomes honest once the underlying surface is consistent enough to inventory and measure, and without it the other dimensions drift because no one outside engineering can tell when they slip.

## Ownership Zone Owns the coherence of the workspace as a multi-package monorepo: the root workspace declaration, the shape and conventions of packages under packagesprompts: logical-model usage, registry name@version uniqueness, zod input contracts, deterministic render, and eval coverage. ## Rubric - **Versioning discipline** — Prompt changes bump version; each name@version is unique in the registry; shipped versions are not silently edited in place. - **Model agnosticism** — Prompts reference logical model names (reasoning-mid, reasoning-high, fast-cheap) and never hardcode vendor model IDs. - **Typed input contract** — Every prompt declares a zod input schema and is rendered through validated input (renderSafe), failing fast on bad input. - **Render purity** — render() produces ChatMessage[] deterministically from validated input with no side effects or hidden state. - **Eval coverage** — Prompts carry eval cases asserting output shape/quality; high-value prompts are not shipped eval-less.

## Ownership Zone Owns the path a new user or contributor walks from a fresh clone to a running local instance with all integrations live. The territory covers the README and quickstart, the .env.example and every variable a real run depends on, the runbook for setting up the GitHub OAuth app and obtaining tokens for GitHub, CircleCI, and Anthropic, the Settings page copy that guides token entry in-product, the MCP server setup guide, and the version pins (Node, package manager) that determine whether install steps even work. Also owns the contract that these surfaces stay in sync with each other and with the actual configuration the code reads at runtime, so that setup instructions do not drift as dependencies and integration points change. ## Rubric - **Runtime-config truth** — The set of environment variables, secrets, and version pins documented for setup matches what the code actually reads and requires at startup, with nothing extra and nothing missing. This is the floor the rest of the rubric stands on: if the documented config is fiction, every other dimension is grading a tour that leads somewhere the code does not live. Excellence looks like a single source of truth that documentation derives from, not two lists drifting apart; the failure mode is a new user copying a .env that boots the server but silently disables a feature. - **First-run path is linear** — A new contributor follows one ordered path from clone to working app, with no branching choose-your-own-adventure between platforms, package managers, or optional integrations until the core path works. Sits on top of runtime-config truth: ordering steps only helps if the steps themselves are real. The bad version is a README that lists prerequisites, configuration, and commands as parallel sections and leaves the reader to sequence them. - **Third-party setup is walked, not waved at** — For every external account, OAuth app, or token the product depends on, the docs name where to click, what scopes or permissions to grant, what to paste where, and how to tell it worked. Only meaningful once the first-run path is linear; otherwise the third-party detour stalls a user mid-sequence with no way back. Excellence reads like a runbook a non-expert can execute; the eye-roll version is a sentence saying create a GitHub OAuth app and configure the callback URL with no link, no field names, and no example values. - **In-product guidance matches the docs** — Settings pages, empty states, and inline help for tokens and integrations agree with the external docs on names, formats, and where to obtain values, and they degrade gracefully when something is missing or wrong. This is a stakeholder-facing dimension: a user who never opens the README should still succeed, and a support conversation should not have to reconcile two different vocabularies for the same token. Bad implementations have a Settings field labeled one way and a README that calls the same thing something else. - **Failure modes are legible to the person hitting them** — When setup goes wrong — wrong Node version, missing env var, expired token, misconfigured OAuth callback — the error the user sees points at the surface they need to fix, not at a stack trace ten layers down. Becomes possible once runtime-config truth is in place: you can only diagnose a missing variable clearly if you know which variables are required. The failure mode is a generic 500 or a TypeError on undefined that sends the user to ask in chat instead of self-serving. - **Doc freshness has an owner and a trigger** — Onboarding surfaces are revisited on a known trigger — dependency bumps, new integrations, version pin changes, settings additions — rather than whenever someone happens to notice rot. This dimension is invisible from the codebase alone: it is about team practice, not file contents. Excellence is a contributor knowing that adding a new env var or integration is not done until the corresponding doc surfaces are updated; the bad version is README drift discovered six months later by a frustrated new hire. - **Time-to-first-success is known** — Someone owns the answer to how long it takes a new contributor to go from clone to a running app with real integrations, and that number is measured from real attempts rather than guessed. The capstone — only honest once the dimensions above hold, because otherwise the number is measuring confusion rather than setup. Stakeholders (maintainers, hiring managers, OSS contributors) can answer is onboarding getting better or worse without reading code; the failure mode is a team that believes setup takes 15 minutes because that is how long it takes them, while every newcomer quietly spends three hours.

## Ownership Zone Every user-facing input surface in the codebase — form fields, URL parameters, API request bodies, file uploads, and any data sourced from external systems — and the validation, escaping, and encoding logic that prevents malicious payloads from reaching execution contexts. This includes input validation at the boundary, output encoding for the rendering context (HTML, SQL, shell, JSON), and the relationship between declared input schemas and the actual sanitization applied downstream. The steward owns the gap between what a user can send and what the system safely executes. ## Rubric - **Boundary validation is declarative** — Input validation lives at the entry point and is expressed in a single source of truth — a schema, type definition, or validation rule that every handler consults. Without this, validation logic scatters across handlers and diverges; a field validated in one endpoint is trusted unvalidated in another, and the gap is invisible until exploit time. Validation is impossible to skip by accident. - **Output encoding matches the context** — Data is encoded for the specific context it enters — HTML entities for HTML, SQL escaping for queries, shell quoting for commands, JSON escaping for JSON. A single encoding function applied everywhere is a sign that the team does not distinguish contexts; the same string safe in HTML is dangerous in SQL. Encoding is applied at the point of output, not assumed to have happened upstream. - **Injection vectors are named and tested** — The team knows which inputs can reach which execution contexts and has written tests that verify each vector is blocked. Without this, injection risks hide in the gap between what the team thinks is validated and what actually is. A new feature that adds a path from user input to a database query is a typed change that surfaces the injection test, not an implicit assumption. - **Dangerous operations are explicit** — Code that interprets user input as code — eval, dynamic SQL construction, template injection, unsafe deserialization — is visible and rare. If the codebase uses these patterns, they are justified in comments, isolated to a small surface, and guarded by strict input constraints. A reader should be able to find every place user input flows into code execution in under a minute. - **Validation failures are observable** — When input validation fails, the event is logged with enough context to detect patterns — repeated failures from the same source, systematic probing of a field, or a new attack vector. A validation failure that disappears silently or is only visible in a debug log is a missed signal; the team should be able to answer whether they are under attack without reading code. - **Security assumptions are documented** — The team has written down what they assume about input — which fields are trusted, which are user-controlled, which sanitization is applied where, and what the consequences are if an assumption breaks. Without this, the next engineer assumes the wrong thing and introduces a gap. Documentation is updated when assumptions change, not written once and forgotten.

## Ownership Zone Every Content Security Policy directive served by the Next.js frontend — script-src, frame-src, connect-src, style-src, img-src, font-src, and the rest — along with each allowed origin, hash, or nonce, the feature or integration that justifies it, and the mechanism (middleware, headers config, meta tag) that delivers the policy to the browser. The zone covers how the policy is composed, how it is rolled out (report-only vs enforcing), how violations are observed, and how the policy stays aligned with the actual set of third parties the product depends on. It also covers the human-facing side: whether product, security, and integration owners can answer what is allowed, why, and what would break if it were removed. It does not own the third-party scripts themselves or the application code that uses them — only the trust boundary that decides what the browser is permitted to load and execute. ## Rubric - **Directive completeness and precision** — The floor the rest of the rubric stands on. Every fetch directive a modern app needs is explicitly set rather than inherited from default-src by accident, and each one lists the narrowest set of sources that actually make the feature work. The bad version is a single sprawling default-src with wildcards and a script-src that grew by accretion; the good version is a policy where you can point at any entry and name what would break without it. - **Provenance of every allowance** — Every origin, hash, and nonce in the policy traces back to a specific feature, vendor, or integration, recorded somewhere a human can read. Without this, the directive surface becomes a graveyard of entries no one dares delete; with it, removing a vendor is a normal cleanup task instead of a multi-hour archaeology dig. This is the dimension the directive inventory and justification-coverage metric exist to make reportable. - **Nonce and hash discipline over unsafe-inline** — Inline scripts and styles are admitted via per-request nonces or content hashes, not via blanket unsafe-inline or unsafe-eval escape hatches. The contrast: a policy that looks strict on paper but quietly carries unsafe-inline because one analytics snippet needed it three years ago is failing this dimension, even if every other directive is tight. - **Violation observability** — Only meaningful once the policy is precise enough to trust: a noisy policy produces noisy reports no one reads. CSP violation reports are collected, deduplicated, and routed somewhere a human actually looks, with enough context (directive, blocked URI, source file, user agent) to tell a real attack or regression apart from a browser extension. Silent enforcement with no report sink is the failure mode this calls out. - **Safe rollout and change discipline** — Becomes possible once observability is in place. New directives or tightened ones go through report-only before enforcement, changes are reviewed against the inventory rather than appended blindly, and there is a known path to ship a fix when a third party rotates a domain. The bad version is editing the policy directly in production and finding out from customer reports. - **Stakeholder legibility** — The capstone, and the dimension that fails most quietly. A non-engineer — a security reviewer, a vendor-onboarding PM, a compliance auditor — can answer what third parties the site trusts, why each is trusted, and what changed last quarter, without reading middleware source. If that question requires grepping the repo, the policy is technically correct but organizationally opaque.

## Ownership Zone Every PostHog integration point across the platform — SDK initialisation and provider wiring on the web surface, every capture, identify, and group call site, autocapture and session replay configuration, feature-flag usage, and the relationship between events emitted in code and what growth, product, and founders consume downstream in PostHog dashboards, funnels, and retention reports. The zone extends to instrumentation gaps in adjacent surfaces (such as CLI or server-side tooling) where product-critical flows happen outside the browser and represent blind spots in the user journey. It also covers the event taxonomy itself — the naming conventions, property shapes, and type-safety guarantees that determine whether data arriving in PostHog is queryable signal or accumulating noise. The steward owns the contract between the code that emits events and the humans who try to answer questions from them. ## Rubric - **Event taxonomy discipline** — Every event name follows a single documented convention and the convention is enforced at the call site, not by downstream cleanup or rename rules in the warehouse. The failure this guards against is the same logical moment shipped under three slightly different string literals from three components, producing three lines in PostHog where there should be one. This is the floor the rest of the rubric stands on: no other dimension is meaningful if the taxonomy is incoherent, because every funnel and dashboard sits on top of names. - **Type-safe emit boundary** — Tracking calls reference a shared, typed catalogue of event names and property shapes rather than passing ad-hoc string literals and untyped property bags. Without this a typo or a renamed property silently breaks a funnel and nobody notices until a quarterly review. Builds directly on taxonomy discipline — the catalogue is the taxonomy made enforceable, and the compiler becomes the first reviewer of every analytics change. - **Identify and group hygiene** — Identify fires at session-start and auth-state-change with a stable user ID, and group associates users with their org or tenant where applicable, before any meaningful event is captured in that session. Without this events land as anonymous noise and org-level analytics are fiction; funnels built on unidentified events silently undercount conversion. Sits alongside taxonomy discipline as a foundational concern — a clean name on an anonymous event is still a half-measurement. - **Coverage of meaningful moments** — Signup, activation, the handful of key product actions, upgrade, error states, and churn-risk moments all fire an event, and coverage is judged by whether a product or growth stakeholder can answer what happened in the user journey from PostHog alone without asking an engineer to query the database. The bad version is a dashboard full of pageviews and autocapture clicks with no domain verbs, where every real question requires a SQL detour. Only meaningful once the taxonomy is stable enough that adding a new event doesn't create ambiguity with existing ones. - **SDK configuration consistency** — PostHog is initialised once per surface with explicit, reviewed settings for autocapture, session replay, cross-subdomain tracking, PII redaction, and feature-flag bootstrap, and those settings agree across client and server and across environments. Configuration disagreements produce data that looks correct in staging and breaks in production, or worse, leaks PII that a privacy review assumed was redacted. Becomes auditable once identify hygiene is in place, because misconfigured init is invisible when users aren't identified. - **Dashboard-to-code alignment** — Every event referenced in a dashboard, funnel, or insight corresponds to a live capture call, and every capture call is consumed by at least one downstream artefact a stakeholder actually looks at. Orphaned dashboard references produce silent zeros that erode trust in the analytics surface; orphaned capture calls waste payload and clutter the event stream so newcomers can't tell signal from legacy. This is a capstone dimension — only meaningful once the taxonomy, type safety, and coverage dimensions are healthy enough that the catalogue of events is stable and enumerable on both sides. - **Analytics health legibility** — A non-engineer can answer are events still flowing and did we lose tracking last week without paging someone, because ingestion volume, event-type cardinality, and identify-rate are monitored or at least reviewed on a known cadence. The bad version is discovering a three-week instrumentation outage when a board deck is being prepared. Sits on top of every other dimension: you can only monitor what you've named, typed, identified, and wired to something a stakeholder reads.

## Ownership Zone Owns the resilience of the Next.js and React framework surface across upgrades — the pinned versions of next, react, react-dom, and eslint-config-next; the App Router conventions (segment filenames, route groups, layouts, server vs client component boundaries); the build and lint gates that catch framework-level regressions before deploy; and the backlog of known framework risks that need to be worked down. Also owns the relationship between the codebase and Vercel's deployment expectations, so that what builds locally builds on Vercel and what renders in dev renders in production. The zone covers everything that determines whether a framework or runtime bump is a routine chore or a silent outage. ## Rubric - **Version pinning discipline** — Framework-critical packages (next, react, react-dom, the matching eslint config) are pinned to exact versions, not caret or tilde ranges. This is the floor the rest of the rubric stands on: until the versions installed in CI, on a fresh clone, and on Vercel are provably identical, every other dimension is grading a moving target. The bad version of this dimension is a lockfile that drifts between environments and an upgrade that lands by accident on a Tuesday afternoon. - **Pre-deploy build gating** — A production build (and the framework's own type and lint passes) runs on every push and PR and blocks merge on failure. Only meaningful once versions are pinned — otherwise the gate is checking a different build than the one that ships. The failure mode this dimension calls out is discovering a broken build from the deploy log instead of from CI; excellence means the first place a framework regression surfaces is a red check, not a white screen. - **Routing and component-boundary correctness** — App Router conventions are followed strictly: canonical segment filenames, deliberate placement of server vs client components, no accidental client-bundling of server-only code. Sits on top of the build gate, because lint and type rules are the mechanism that makes these conventions enforceable rather than tribal. The bad version is a file named almost-but-not-quite right that silently fails to route, or a use client added to silence an error without understanding what crossed the boundary. - **Upgrade rehearsal and risk backlog** — The team treats framework upgrades as a rehearsed activity, not an emergency: known framework risks, deprecations, and migration steps live in a tracked backlog with priorities, and majors are taken on a deliberate cadence with a known rollback. Becomes possible once the prior dimensions exist, because rehearsal is only credible when versions are pinned and CI catches regressions. Excellence here is a reader being able to answer what's the next framework risk we owe time to without asking a person. - **Deployment-target fidelity** — The local and CI build environment matches what Vercel (or the equivalent target) actually runs: Node version, build command, environment variables, edge vs node runtime choices, and image/route configuration. The bad version is the works on my machine class of incident where the production runtime quietly disagrees with the dev runtime about a server component, a route handler, or a cached fetch. - **Stakeholder-legible upgrade posture** — A non-engineer stakeholder (PM, founder, ops) can answer are we current, are we exposed, and what would an upgrade cost without paging an engineer to read package.json. This is the capstone — only honest once pinning, gating, conventions, and the risk backlog are in place, because otherwise the answer is a guess dressed up as a status. Excellence is a posture that can be reported on, not folklore held in one engineer's head.

## Ownership Zone Adherence to the industrial/brutalist design system: color tokens, typography contracts, component variant usage, layout patterns, and zero-radius enforcement across the Next.js app. ## Rubric - **Token discipline** — Components use defined color tokens (primary, surface, surface_two, text-primary, text-muted, error, warning, success) and their documented scale steps. No ad-hoc hex values, no non-existent tokens like brand.400, no whiteAlpha borders. - **Typography contract** — Space Grotesk for headings/body/buttons, JetBrains Mono for labels/data/code. Text styles (monoLabel, monoBody, monoSmall) are used for their documented purposes. Uppercase + wide tracking signals system text, not human-readable content. - **Variant usage** — Buttons use industrialPrimary, industrialOutline, or industrialCta — never bare Chakra solid/outline. Inputs use the theme variant without inline bg/borderColor/_hover/_focus overrides. Tables use variant bordered. Components use AppModal, Card, DataTable wrappers rather than raw Chakra primitives. - **Surface and border hygiene** — Surfaces are delineated by surface_two.500 borders, never drop shadows. No border-radius anywhere — the theme overrides all radii to 0. No CircularProgress or rounded elements that contradict the zero-radius constraint. - **Layout pattern conformance** — Landing pages use the 1440px container with border rails and section dividers. Blog/content headers use the 7fr/5fr grid with yellow breadcrumb label pattern. Auth pages use centered VStack with hyperspace animation. App pages use Layout with sidebar at 240px.

## Ownership Zone Correctness and completeness of marketing blog post PRs in the Next.js app: the post page file under packages/app/src/pages/blog/ (named for the post slug), its BLOG_POSTS metadata registration, hero and card image wiring, SEO and structured data, sitemap inclusion, and conformance to the blog component system, so a correctly-built post can be approved, merged, and deployed without manual review. ## Rubric - **Post registration integrity** — Every new post has both a page file under packages/app/src/pages/blog/ named for its slug and a matching entry in BLOG_POSTS (consts/blogPosts.ts). The slug is unique, kebab-case, and consistent across the filename, the metadata.slug field, and the page's metadata lookup; the default export is the PascalCase form of the slug. No orphaned page without a registry entry, and no registry entry without a page. - **Metadata completeness & correctness** — The BlogMetadata entry has all required fields well-formed: title, description, ISO date (YYYY-MM-DD), tag, h1, readTime, a cardImage URL, and an author key that exists in BLOG_AUTHORS. The page reads every displayed value from the metadata constant rather than hardcoding titles, dates, or image URLs in JSX. - **Hero image & asset wiring** — cardImage points to the Supabase assets/blog bucket URL for the post slug, is webp, and the referenced asset was actually uploaded (not a placeholder or dead link). The image is wired through BlogHeroImage and SEOHead ogImage, and its aspect ratio is reasonable for OG cards (about 1.91 to 1). - **SEO, structured data & sitemap fidelity** — SEOHead is wired with the canonical URL via canonicalUrl(BLOG_ARTICLE(slug)), the standard 'Title | HyperServe Blog' title format, the cardImage as ogImage, and jsonLd from buildBlogPostingJsonLd(metadata). Open Graph, Twitter card, canonical, and BlogPosting JSON-LD are present and reference the real post; trackPageView fires for the article. The post is reachable from sitemap.xml.tsx, which derives blog URLs and lastmod from BLOG_POSTS via getAllBlogMetadata, so the registry entry and its ISO date must be valid for the post to be indexed. - **Component & markup conformance** — The post uses only the approved blog components in the canonical structure (BlogLayout wrapping BlogHeader, BlogTLDR, BlogHeroImage, BlogSection and BlogHeading content, BlogCTA, then RelatedPosts) rather than raw Chakra or ad-hoc markup. JSX quotes and apostrophes are escaped as HTML entities, and component props match their documented contracts. - **Build & link safety** — The PR typechecks (no TS errors), removes unused imports (e.g. Link when there are no internal links), and is scoped to the expected files without stray changes. Internal blog links resolve only to slugs that already exist in BLOG_POSTS, with no dead references.

## Ownership Zone WCAG 2.1 AA accessibility of the SvelteKit dashboard: keeping the pnpm a11y:auth regression gate green and correctly extended as new surfaces ship, semantic/ARIA and keyboard correctness across authenticated and public surfaces, color-contrast token discipline, status/error messaging, and the compliance audit trail under compliance/accessibility/. ## Rubric - **Gate coverage integrity** — New authenticated routes, modals, dropdowns, and popovers are registered in PROFILES/subSurfaces (a11y-auth.mjs) with locale-stable selectors (data-testid/aria-*), so the delta-only a11y:auth ratchet actually scans them instead of silently missing coverage. - **Semantic structure & ARIA** — Headings, landmarks, lists, labels, roles, and ARIA attributes expose intent to assistive tech and respect the role allowlist — guarding the axe rule families that have fired here (label, dlitem, nested-interactive, select-name, aria-input-field-name, aria-prohibited-attr). - **Keyboard & focus management** — Every interactive control is reachable and operable without a pointer; route changes, dialogs, and async panels move or restore focus predictably; scrollable regions are focusable. Covers the non-automatable WCAG criteria axe cannot catch. - **Contrast & non-text affordances** — Text meets 4.5:1 and focus rings / essential non-text content meet 3:1 in BOTH light and dark mode, expressed through semantic color tokens rather than raw primitives (per contrast-audit.mjs gating policy). - **Status & error messaging** — Asynchronous changes, validation errors, and toasts announce via aria-live / role=status / role=alert appropriately (WCAG 4.1.3) — info/success/warning use the polite status convention, only true errors use alert. - **Compliance trail currency** — statement.md, roadmap.md, audit-log.md, and the contrast report stay in sync with shipped work and the WCAG 2.1 AA / SGQRI 008-2.0 target, and governance gaps (réaudit cadence, public statement, VPAT) stay visibly tracked.

## Ownership Zone I own accessibility quality for the React component layer in the client/ directory — every interactive surface a user can see, hear, focus, or be trapped inside. That spans modal dialogs and their focus management, the conversation UI and its live-updating message stream, the onboarding flow with its audio and form interactions, and the shared primitives (buttons, badges, inputs, toasts) that compose all of the above. I am responsible for semantic HTML and ARIA correctness, keyboard reachability and focus order, color contrast under the active theme, screen reader behavior including live regions and route-change announcements, and the automated regression coverage that keeps these properties from rotting between releases. I am also responsible for the legibility of accessibility status to non-engineering stakeholders — whether someone outside the team can answer what conformance level we ship at and what is currently blocking it. ## Rubric - **Semantic foundation** — Interactive elements use the native control that already encodes role, state, and keyboard behavior; ARIA is reached for only when no semantic element fits. This is the floor the rest of the rubric stands on — a div masquerading as a button invalidates every downstream claim about keyboard support, focus, or screen reader behavior, because the assistive tech never knew there was a control there to begin with. The bad version is a tree of clickable divs with onClick handlers and bolted-on role attributes; the good version is boring HTML that mostly just works. - **Keyboard and focus discipline** — Only meaningful once the semantic foundation is in place: every interactive element is reachable and operable by keyboard, focus order matches visual order, focus is visibly indicated, and focus is trapped and restored correctly across modals, drawers, and route changes. The failure mode to watch for is the keyboard user who tabs into a modal and cannot escape, or who dismisses one and is dropped at the top of the document with no idea where they were. - **Screen reader truthfulness** — Sits on top of semantics and focus: what a sighted user perceives and what a screen reader announces are the same story, told in the same order. Dynamic content (streaming messages, toasts, validation errors, route changes) is announced through appropriate live regions or title updates rather than appearing silently; decorative content is hidden from the accessibility tree rather than narrated as noise. The bad version is a chat UI where new messages render visually but the screen reader stays silent, or where every icon is read aloud as image image image. - **Perceptual robustness** — Color contrast meets WCAG AA across both text and non-text UI under every supported theme, information is never conveyed by color alone, and the UI remains usable at 200% zoom and at the platform's reduced-motion and high-contrast settings. This dimension is what catches the regressions a theme rollout or a designer's palette tweak quietly introduces, where the pixels look fine to the person shipping them and unreadable to someone with low vision. - **Regression coverage** — Becomes possible only once the dimensions above have a defined good state worth defending: automated checks (axe-style audits, focus and keyboard tests, contrast tests) run in CI on the surfaces that matter, fail loudly on regression, and are wired into the same PR gate as the rest of the test suite. The bad version is a one-time audit spreadsheet; the good version is that an accidental aria-label removal or a contrast-breaking color change cannot land without someone explicitly overriding a red check. - **Conformance legibility** — The capstone — only honest once the underlying surface is consistent enough to measure. A non-engineering stakeholder (PM, founder, support, legal) can answer what conformance level the product ships at, what the current blocking violations are, and when they will be resolved, without reading code or paging an engineer. The failure mode is an a11y posture that exists only in individual engineers' heads and surfaces only when a customer or auditor asks an uncomfortable question. - **Triage and severity discipline** — Accessibility findings are classified by impact and WCAG level, not by whoever shouted loudest; Level A blockers are treated as release-blocking, AA issues are scheduled, and moot findings are explicitly closed with reasoning rather than left to drift. This is what separates a team that has an accessibility practice from a team that has an accessibility backlog — the latter accumulates findings indefinitely because nothing distinguishes a screen-reader-broken flow from a nice-to-have aria-describedby.

## Ownership Zone Owns the contract surface between the standalone MCP server process and the main web application that shares its data and operations. This includes the tool definitions exposed by the MCP server, the prompt templates that shape how those tools are described to LLM clients, the HTTP endpoints the web app exposes for MCP-mediated traffic, and the shared understanding of PR data shapes and available operations that both sides depend on. The zone covers how schemas, tool catalogs, and prompts evolve over time without the two processes silently drifting, and how MCP clients (and the humans configuring them) learn what tools exist and what they do. ## Rubric - **Single source of truth for shared shapes** — PR data shapes, tool argument schemas, and operation contracts are defined once and consumed by both the MCP server and the web app, rather than re-declared on each side and kept in sync by hope. This is the floor the rest of the rubric stands on: until both processes are reading from the same definitions, every other dimension is grading two artifacts that may already disagree. The bad version is parallel TypeScript types or hand-written JSON schemas that look similar at a glance and diverge field-by-field over months. - **Tool catalog discipline** — Only meaningful once shared shapes are in place: each MCP tool has a clearly named purpose, non-overlapping responsibility with its neighbors, typed arguments, and a declared result shape. Tools fail loudly with structured errors rather than returning success with an empty payload, and deprecated tools are removed or explicitly marked rather than left to rot in the catalog confusing clients. - **Prompt and description fidelity** — Tool descriptions and prompt templates accurately reflect what the tools actually do, including their argument semantics, side effects, and limits. The bad version is a description written when the tool was first added that no longer matches its behavior, leaving LLM clients to call tools based on a fictional contract; the good version has descriptions that change when behavior changes, treated as part of the contract rather than docstring decoration. - **Versioning and evolution discipline** — Becomes possible once the catalog and shared shapes are stable enough to reason about: changes to tool signatures, prompt templates, or response shapes are made with awareness of who is on the other end of the wire. Breaking changes are visible as breaking, additive changes are genuinely additive, and the team has an answer to *what happens to a client pinned to last month's contract* that isn't a shrug. - **Cross-process integration testing** — The contract is exercised end-to-end, not just unit-tested on each side independently. A test that boots both surfaces and walks through representative tool calls catches the divergence that two passing test suites on either side will miss; without this, the first signal that the contract broke is an LLM producing nonsense in production. - **Client-facing legibility** — The capstone, only honest once the dimensions above hold: a non-engineer integrating an MCP client (an analyst configuring Claude Desktop, a PM wiring up an agent) can answer *what tools does this server expose, what do they do, and what do I pass them* from the server's own self-description, without reading source. If the answer requires pinging an engineer or reading the implementation, the contract is leaking out of the artifact that's supposed to carry it.

## Ownership Zone Owns the Astro static site build pipeline end-to-end: the integrity of every `astro build` run, the warnings and errors it surfaces, the wall-clock time it takes, and the health of the inputs the build consumes (component imports, frontmatter contracts, image references, route collisions, layout integrity). Covers the relationship between source content and built output across the full file tree, the CI signal that gates deploys on a clean build, and the visibility of build health to non-engineering contributors who edit content but do not read build logs. Does not own runtime behavior in the browser or content authorship itself — only whether what authors and developers commit produces a trustworthy, fast, warning-free build artifact. ## Rubric - **Build determinism** — The same commit produces the same build output, the same warning set, and roughly the same duration on every run. This is the floor the rest of the rubric stands on: until the build is deterministic, every other dimension is grading noise. Flaky failures, order-dependent warnings, and "it built last time" are the failure modes this dimension calls out. - **Warning hygiene** — Warnings are treated as signal, not wallpaper. A clean build means zero warnings on main, every warning that does appear has a known owner and a known fate (fix, suppress with reason, or upstream issue), and new warnings fail loudly in CI rather than accumulating into background noise nobody reads. The bad version: a build log with 40 warnings everyone scrolls past. - **Input contract enforcement** — Only meaningful once the build runs cleanly: the things the build consumes — component props, frontmatter schemas, image paths, collection entries, route definitions — are validated at build time against a declared contract, so a typo in a content file or a renamed component fails the build with a precise message rather than producing a silently broken page. Contracts are explicit and versioned, not implicit in whatever the templates happened to read last. - **Build performance budget** — Builds complete within a stated time budget appropriate to the site's size, and sustained drift against that budget is treated as a regression with an owner. Sits on top of determinism: you can only defend a budget when run-to-run variance is small. The bad version is a build that quietly grew from 30 seconds to 4 minutes over a year because nobody was watching the trend. - **Content-author feedback loop** — Becomes possible once input contracts and warning hygiene are in place: a non-engineer who edits a markdown file or swaps an image gets a clear, local signal about whether their change will build, in language they understand, before it reaches main. Excellence here is judged by whether content contributors can self-serve — not by how elegant the build internals are. The failure mode is a content editor whose PR breaks the build and who cannot tell why without pinging an engineer. - **Deploy gate trust** — The capstone — only honest once the dimensions above hold: a green build on main is treated as sufficient evidence to deploy, and a red build actually blocks. No one routinely overrides the gate, no one ships from a local build to dodge CI, and stakeholders trust that "the site builds" means the site is in fact deployable. When the gate has been bypassed, there is a recorded reason and a follow-up.

## Ownership Zone Version, identity, MCP server name, skill slug, and install-instruction consistency across the marketplace manifest, plugin manifest, SETUP.md, and README for the Steward Claude Code plugin. ## Rubric - **Version synchronization** — Marketplace version, plugin version, and any version references in SETUP/README move together on every release; no stale version strings linger after a bump. - **Identity and naming consistency** — Plugin name, MCP server name, marketplace name, and brand references match across manifest, SETUP, README, and skill files; old names (e.g. contextgraph) do not leak back in after a rename. - **Skill registration parity** — Every shipped skill under plugins/steward/skills/ is reflected with its real slug (e.g. steward:define-steward) in README and SETUP verification steps, and removed skills are removed from docs. - **Install and verify instructions** — Documented install, reload, update, /mcp check, and skill-availability check match what the current marketplace and plugin manifests actually expose; commands users are told to run still work. - **MCP server contract surface** — The mcpServers.steward declaration in plugin.json (name, type, url) matches what skills and docs tell users to expect, and changes to the server name or transport are propagated through every artifact.

## Ownership Zone Every image asset the site depends on — food item photos, guide illustrations, and the OG image generation pipeline — together with the references that bind them to content entries, components, and route templates. This covers the full lifecycle: which images exist on disk, which are referenced, which are generated on demand, whether each rendered page resolves to a real file, and whether the social-sharing surface produces valid output for every route. The zone includes the inverse direction too: assets that exist but are no longer referenced, and references that point at paths nothing produces. It does not extend to image content choices or visual design — only to whether the pipeline from authored reference to delivered pixels is intact, lean, and observable. ## Rubric - **Reference resolvability** — Every image path named in content, components, or templates resolves to a real, non-empty file at build time, and an unresolvable reference fails the build loudly rather than shipping a broken `<img>` tag to production. This is the floor the rest of the rubric stands on: until references resolve, sizing, generation, and orphan hygiene are all grading work that may render as a broken icon anyway. - **Generated-image pipeline integrity** — Routes that rely on generated imagery (OG cards, derived thumbnails, templated illustrations) produce valid, correctly-dimensioned output for every input the route can receive, not just the handful exercised during development. The bad version of this dimension is a generator that silently emits a 0-byte file or a fallback placeholder for half the catalogue and nobody notices until a link is shared. - **Asset library hygiene** — The set of files on disk stays close to the set of files actually referenced; orphans are pruned on a known cadence rather than accumulating as repo weight, and additions are deliberate rather than drive-by. Only meaningful once reference resolvability is in place — otherwise pruning is dangerous because you cannot trust the reference graph you are pruning against. - **Delivery weight discipline** — Images are sized, compressed, and formatted for the surface that actually consumes them, with the source-of-truth original kept separate from the web-delivery variant. A rubric-failing setup ships 4MB hero JPEGs to mobile, has no convention for which dimensions and formats are canonical, and treats every new image as a one-off decision. - **Authoring ergonomics** — Sits on top of the dimensions above: a content author can add a new food item or guide without learning the asset pipeline, knows exactly where to drop the image and how to reference it, and gets immediate feedback when they get it wrong. When this fails, you see the same handful of engineers re-explaining the conventions in PR review and authors avoiding image-heavy entries entirely. - **Stakeholder-facing visibility** — The capstone — only becomes possible once the surface is consistent enough to measure honestly. A non-engineer (content owner, founder, marketer checking a social share) can answer questions like how many pages have working previews, which entries are missing imagery, and whether last week's content drop rendered cleanly, without asking an engineer to grep the repo.

## Ownership Zone Owns the GitHub OAuth flow end-to-end — login initiation, callback handling, session establishment, and logout — and the full lifecycle of every httpOnly cookie token stored on behalf of the user (GitHub, CircleCI, Anthropic, and any future provider tokens that ride the same cookie surface). Responsible for how token expiry, revocation, corruption, and CSRF-class attacks are detected and surfaced, so that a stale or hostile credential fails cleanly at the auth boundary rather than cascading into downstream API routes. Guards the contract between edge-runtime auth routes and server-side proxying routes: which routes are allowed to assume a valid session, how that assumption is validated, and what happens when it does not hold. Also owns the operator-facing visibility into auth health — who is logged in, why logins fail, and which routes are protected — so that session-layer incidents are diagnosable without grepping the codebase. ## Rubric - **Cookie hygiene as the foundation** — Every token cookie is httpOnly, scoped, signed/encrypted as appropriate, and has a single owner that knows its set, read, and clear paths. This is the floor the rest of the rubric stands on: until cookie semantics are unambiguous, every other dimension is reasoning about state that other code paths can quietly mutate. The bad version is tokens written in one place and forgotten in another, where logout leaves residue and nobody can say which routes touch which cookie. - **CSRF and callback integrity** — The OAuth callback verifies that the response it is processing is the one this browser initiated: state parameter generated, stored, and checked; redirect targets constrained to a known set; replayed or cross-origin callbacks rejected loudly. Builds directly on cookie hygiene, since state itself rides the cookie surface. The failure mode this dimension exists to prevent is a callback that happily mints a session for whoever shows up with a valid-looking code. - **Failure-mode behavior under bad credentials** — Expired, revoked, malformed, and impersonated tokens produce a single well-defined outcome at the auth boundary: the session is invalidated, the user is sent through re-auth, and downstream handlers never see a half-valid credential. Only meaningful once cookie hygiene and callback integrity are in place; otherwise the system cannot tell a bad token from a missing one. The bad version is a 500 from a deep API call because a GitHub token silently expired three days ago. - **Route auth contract clarity** — Every server route falls into a known category — public, session-required, session-optional, internal — and the category is enforced in one obvious place rather than re-derived per handler. This sits on top of failure-mode behavior: a route only benefits from a clean failure path if it actually invokes the validator. The bad version is the auth check copy-pasted into some handlers, forgotten in others, and impossible to audit without reading every file. - **Stakeholder visibility into auth health** — Non-engineering stakeholders (support, ops, the person triaging a Monday-morning incident) can answer questions like did logins start failing last Thursday, is this user actually authenticated, and which provider token is stale — without paging an engineer to read logs. This dimension is not visible from the codebase alone; it is judged by whether the people downstream of the auth boundary can self-serve. Becomes possible only once the route contract and failure modes are consistent enough to measure honestly. - **Cross-provider token coherence** — When more than one provider's token rides the same session, their lifecycles are reasoned about together: a revoked GitHub token does not leave a live CircleCI cookie behind, and adding a new provider follows a known pattern rather than inventing a fourth cookie shape. This is partly an organizational property — it depends on whoever adds the next provider knowing the pattern exists — and partly a code property. The bad version is each provider integration looking like it was written by someone who had never seen the others. - **Auditability of session decisions** — Every session-affecting decision (issued, refreshed, rejected, cleared) leaves a trace that an operator can reconstruct after the fact, with enough context to distinguish user error from attack from bug. The capstone dimension: only meaningful once the decisions themselves are consistent across cookies, callbacks, failure modes, and routes. The bad version is a user reporting they were logged out and nobody, including the steward, being able to say why.

## Ownership Zone Subscription lifecycle state machines, usage metering, free-tier enforcement, Stripe billing integration, and API access gating. ## Rubric - **State machine integrity** — Subscription status transitions (free_tier_active → grace_period → exceeded; active → past_due → unpaid → canceled) match the intended lifecycle, leave no orphan states, and trigger the correct side effects (content lock/unlock, emails, analytics). - **Usage metering accuracy** — CloudFront log parsing, bandwidth aggregation, storage tracking, and Stripe metered billing event submission faithfully reflect real consumption without double-counting or data loss. - **Free tier enforcement** — Limits (video count, file size, bandwidth), grace period timing, alert email thresholds, and content locking/unlocking apply consistently and at the correct thresholds defined in subscription constants. - **Access gating consistency** — SubscriptionGuard, plan checks, skipSubscriptionGuard decorators, and demo user exceptions enforce the correct access boundary for every API route without gaps or false blocks. - **Stripe webhook fidelity** — Incoming Stripe subscription and checkout events map to the correct internal state changes without gaps, silent failures, or status/plan mismatches between Stripe and the subscriptions table.

## Ownership Zone Friction and legibility of moving a backlog item from queued to merged in production, across the MCP server, the CLI, and the plugin: the lifecycle state machine and its truthful linkage to PRs and branches, the MCP and notification surface that tells agents and humans what to do next, and the trust signals that let a workspace widen backlog autonomy over time. Excludes PR-review verdict quality (owned by PR Thread Responsiveness and review-policy) and CI correctness. ## Rubric - **Lifecycle state truth** — A backlog item's state (queued / in_progress / proposed / done / dismissed) and its PR or branch linkage always reflect reality. Orphaned claims, expired-lease ghosts, items stuck after their PR merged or closed, and false orphaned-PR warnings are defects. - **Deliverable and contract legibility** — peek / claim / list responses expose what an agent needs to act correctly: the intended deliverable (pull_request vs note), the recommended next action, and lifecycle copy that does not push a PR onto note-shaped or already-done work. - **Progress visibility** — In-flight work is countable and surfaced. queued, in_progress, proposed, and awaiting-merge are distinguishable in counts and responses, and a claimed-but-PR-less item, a green-but-idle PR, or a done-but-unmerged item never sits invisibly. - **Delivery handoffs** — At each gate where a human must act — PR ready to review, ready to merge, conflicted, CI red, or a workspace stuck with un-executed backlog — the user is notified promptly and clearly with the correct next action. - **Selection continuity** — The path from signal to work stays coherent: consult's top-concern set and the queue's top item do not silently diverge, so the agent acts on what the stewards actually flagged rather than drifting to a different item. - **Autonomy trajectory** — The workspace's chosen autonomy level (merge-block threshold, auto-flow eligibility) is respected and legible, and the clean delivery history needed to justify widening autonomy over time is visible rather than hidden.