{
  "generated_at": "2026-09-03T02:36:06.997882347Z",
  "enabled": true,
  "agents": [
    {
      "id": "wayfarer",
      "name": "Wayfarer",
      "role": "Jack-of-all-trades",
      "responsibilities": "Everything without a dedicated specialist: general features, fixes, refactors, docs, tooling, and any task that spans several specialties at once. The road decides your work; you are ready for all of it.",
      "fallback": true,
      "issues": 252,
      "succeeded": 228,
      "failed": 5,
      "main_attempts": 575,
      "tokens_in": 1694144096,
      "tokens_out": 7378777,
      "cost_usd": 781.21644435,
      "last_active": "2026-09-02T15:42:08.652931741Z",
      "memory": [
        "For a \"fee deducted from X instead of added on top\" bug, check whether the same deduction is duplicated in a frontend preview/estimate function mirroring the backend math — both usually need the identical fix, plus any UI copy that names the deducted field as \"you pay X\" needs updating to distinguish the base amount from the total charged.",
        "For ghomemish's r3-domotic Frame shell, \"picker looks full-screen instead of like the room list\" bugs are fixed by moving the component from `overlays__row--middle` (full-screen `.sheet` video views) into the `overlays__row--bottom` slot `Home` occupies and dropping the `.sheet` class — no new data model (e.g. per-camera room association) is needed since the compact `.panel home` room-button styling is already shared CSS.",
        "When a prior attempt's diff replaces a raw-JSON settings field with a friendlier row editor while keeping the same storage key/shape, verifying it is fast — just check the new component's hooks/imports are already present in the file and that the edited setting key matches the backend's settings-definitions shape, no build needed.",
        "For ghomemish's Frame bottom nav, a per-category-scoped action (rendered in every category's room-list header) is usually better modeled as its own top-level bottom-nav tab (mirroring the existing Cameras tab pattern) than left duplicated across every category screen.",
        "For ghomemish's r3-domotic room/device categorization, when a device's control-domain set contains a \"primary identity\" domain (like media_player) that should override incidental secondary controls, model it as a per-device category function that special-cases that domain first, rather than a per-control-domain union — and mirror the same function on both backend and frontend since each computes its own aggregation independently.",
        "For r3-quest, before assuming an OIDC \"login fails for new user\" report is an app bug, check `findOrCreateByOidcUserId` — it already auto-provisions on first login, so the real cause is usually a Keycloak realm-level federated-identity setting outside the app's code.",
        "When an issue's acceptance criteria need human-held credentials, still ship the anticipated tooling and a runbook plus the non-obvious discovered facts, then escalate — an actionable escalation beats a bare \"please do this.\"",
        "When a \"new location\" enhancement asks for defaulting/search/map/recent-picks, check whether the module already exposes a \"my own past records\" list endpoint (here `GET /quests/mine?role=giver`) before assuming recent-locations needs new backend persistence — it often doesn't.",
        "When live-testing a session-establishing HTTP endpoint in an app with `trust proxy` enabled and `secure`/`sameSite=none` cookies gated on `NODE_ENV=production`, always send `X-Forwarded-Proto: https` on direct-port curl requests — otherwise the complete absence of a Set-Cookie header on even known-working flows will look like a bug in the new code when it's actually the test harness lacking the proxy header the app expects.",
        "For an enhancement issue whose sibling registration endpoint already exists, the fastest path is to mirror that sibling's controller/service/DTO/spec file-for-file rather than inventing new structure, keeping the diff minimal and consistent with the codebase's established pattern.",
        "When decomposing an epic whose wording references a not-yet-built subsystem (\"after receiving payment\"), find the nearest implemented lifecycle state to anchor on and say so explicitly in the sub-issue, rather than blocking the chain on the missing subsystem.",
        "When an epic asks for a new access/visibility tier, check whether the codebase already has a *mechanism* axis (dispatch mode, assignment mode) covering one of the requested tiers — model the new tier as an orthogonal audience axis over it rather than widening the existing enum.",
        "When an epic-labeled issue's body bundles a data-model-requiring feature (new column+migration+endpoint) alongside frontend-only reuse-of-existing-endpoint features, that's a strong, fast signal to decompose rather than implement as one change.",
        "For a github-agent optimizer digest proposing a prompt tightening, always check the cited example issues' own comment threads against prior tightenings on the same prompt file before implementing — a digest can recycle already-debunked examples verbatim, and the real gap (if any) usually only shows up in issues closed after the most recent prior tightening merged.",
        "For r3-quest's onboarding flow specifically, `PlatformAuthProvider`/`TenantProvider` cache user permissions and tenant membership at app mount only, so any handler that grants a role/tenant mid-session (like completeOnboarding) must explicitly call `refreshUser()`+`refreshTenants()` before navigating, or the sidebar/branding silently show the stale pre-grant state until a full reload — and always double check which Postgres instance (`docker inspect \u003ccontainer\u003e --format '{{.Config.Env}}'`) a DB finding came from before treating it as evidence, since this repo has multiple same-named-but-unrelated dev databases.",
        "For r3-quest OIDC \"social login fails\" bugs, check whether the mobile exchange path (`quest-auth.service.ts`) mirrors the web callback's email-fallback chain (`email → preferred_username`) — this app-owned mobile code is where a real, fixable divergence often hides even when the ultimate hard-fail lives in the off-limits `@r3/backend` package.",
        "For a github-agent escalation where the console evidence and code both look plausible but the issue persists, checking the *running* container's actual start timestamp against the fix commit's timestamp (and grepping its compiled dist for the fix string) is often the fastest way to distinguish \"code is wrong\" from \"code is right but never deployed.\"",
        "When an issue's prior session left a github-agent \"no completion marker\" comment, check `git log`/`git diff` on the branch first — the real fix is often already committed and just needs verification plus a report, not a redo.",
        "When a bead's notes say a fix is implemented and just awaiting live verification, checking `git log`/`git show` for the actual committed diff first (before re-deriving the fix from scratch) reliably confirms the prior session already did the real work.",
        "For r3-platform apps, `@r3/frontend`'s `\u003cVersionCheck\u003e` component defaults to a hard `window.location.reload()` on any version.json mismatch or fetch failure at tab-focus time — always check whether the app passes a custom `onMismatch` (banner pattern) before assuming a \"page refreshes on tab switch\" bug is app-specific custom code.",
        "When a github-agent frontend redirect bug keeps recurring across attempts, grep every call site of the redirect-triggering function (e.g. every `login(path)` call) rather than trusting the most recently-touched component — the real trigger is often a different, unrelated call site than the one prior attempts patched.",
        "When an enhancement's acceptance criteria say a form should be \"pre-filled from\" a past record, check whether the existing form's own submit-time validation already handles the field you'd otherwise need new code to re-gate (here, the assigned-adventurer requirement already blocked submission until re-picked, so leaving that field null on clone needed zero extra logic).",
        "When a tool's own scratch/tmp filesystem shares the same full root disk as Docker, redirecting via `export CLAUDE_CODE_TMPDIR=/dev/shm` restores the ability to run any shell command at all, even when the actual build/verification step remains blocked by the underlying disk-space shortage.",
        "When a \"show more details\" board/list enhancement needs a value nobody currently returns (like distance), check whether the value is already computed transiently elsewhere in the request path (here, haversineKm was already computed for radius filtering) before treating it as a new data-model/contract layer — often it's just one additional parameter threaded through an existing mapper call.",
        "For a github-agent \"investigate disk space\" chore on the live host, `docker buildx du` (not `docker system df`, which under-reports it) is where the real hog usually is — buildx's build-cache store grows independently of images/containers and is invisible to plain `docker prune`; the safe, ship-it-enabled fix is a new global interval-gated sweep (mirroring the optimizer/r3-update/gleaner pattern) running `docker image prune -f` + `docker buildx prune -f --filter until=\u003cmin_age\u003e`, and any new sentinel file should resolve next to the binary (like `defaultOptimizerSentinelPath`) rather than hardcoding `/tmp/...` like the older r3-update sweep still does.",
        "When an enhancement's acceptance criteria describes a UI label needing a counterparty's name that the current API response never exposes, check whether a generalized cross-module query (like a `ProfilesForUsers`-style contract) already used elsewhere for the same enrichment purpose can be reused with a status-gated call in the existing detail-fetch controller method, rather than treating it as out-of-scope or building new plumbing.",
        "When a branch's HEAD commit already implements the exact GitHub-issue title and the thread only shows a bot's \"no completion marker\" note, verifying frontend↔backend contract field-for-field (controller/DTO vs. frontend types) plus i18n key-set parity is enough to confirm correctness without redoing the implementation.",
        "When an epic bundles a \"deep-link to an external app\" feature with a \"new conversation subsystem\" feature, check whether the deep-link's data is already in the existing read model — it usually is, making it a standalone frontend-only child that ships without waiting on the heavy sibling.",
        "For r3-quest gh-183, a prior session's table-with-sortable-headers + threaded sortDir (contract→controller→service, SQL ORDER BY direction, and cursor comparator flip for keyset desc pagination) was a complete, correct pattern for \"add clickable sortable column headers\" enhancements — worth mirroring for similar sortable-list asks.",
        "For a github-agent issue whose branch already carries an \"interrupted run\" recovery commit, `git show \u003csha\u003e -- main.go` usually reveals a complete, self-documenting implementation (comments citing the issue number) that only needs a build/vet/test pass plus missing-docs backfill and a report — not a redo.",
        "For a fleet-wide \"audit setting X across all monitored repos\" chore, build the inventory by YAML-parsing `git ls-files`-tracked compose files rather than `find`, since untracked host-local override files are what actually deploy and belong in the report as a separate human action.",
        "For \"set mem_limit on every docker-compose service\" issues where the repo has just one tracked compose file with one service, the full workflow (config resolve, build, up, health/OOM/stats check, down) completes comfortably within a single pass — no need to budget-box or split verification.",
        "For a \"set mem_limit on every service\" enhancement, a live bring-up with `docker stats` right after start is the cheapest way to confirm the chosen limit isn't starving the service (compare actual RSS to the cap) before reporting.",
        "For \"set mem_limit on every docker-compose service\" enhancements on a Node service, pairing `mem_limit` with a `NODE_OPTIONS: --max-old-space-size` at ~75% of the cap (both overridable via env with a compose default) matches the issue template's own suggestion and gives V8 a chance to GC before an OOM-kill.",
        "For \"set mem_limit on every docker-compose service\" issues on a single-compose-file repo with a currently-running persistent stack, the full loop (edit, config resolve, commit, `docker compose up -d --build`, health + OOMKilled + `docker stats` check) is cheap enough to complete in one pass and gives strong evidence the caps aren't starving anything.",
        "For R3-securitar's two-file compose setup (build in docker-compose.yml, r3-securitar in docker-compose.override.yml), the override service's local .env holds live production Sonar/GitHub secrets, so live bring-up verification for mem_limit-style issues should be skipped for that service and reported as intentionally deferred rather than attempted.",
        "For \"set mem_limit on every docker-compose service\" issues, when a needed host port is already occupied by an unrelated container, verify the service via a manual `docker run --memory=\u003ccap\u003e -p \u003calt-port\u003e:...` against the built image instead of editing the compose file's port mapping — keeps the diff minimal while still proving OOMKilled=false.",
        "For \"set mem_limit on every docker-compose service\" issues, `docker compose -f \u003cfile\u003e config` (and `--profile \u003cname\u003e config` for profile-gated services) is enough to prove non-default-profile services parse correctly without disturbing them live, while the default-profile service gets the full build+up+health+stats treatment.",
        "For \"set mem_limit on every docker-compose service\" issues on a repo with a single service, pairing mem_limit with a proportional NODE_OPTIONS --max-old-space-size (when the service is Node-based) and verifying with a live `docker compose up -d --build` + `docker stats` + OOMKilled check is a fast, complete, single-pass workflow.",
        "For rackanoid's single docker-compose.yml with a Go backend + nginx frontend, \"set mem_limit on every service\" is a two-line addition (mem_limit env-overridable per service) fully verifiable in one pass via config resolution + live up -d + docker stats, with no NODE_OPTIONS pairing needed since neither service is Node-based.",
        "For \"set mem_limit on every docker-compose service\" issues, check each service's Dockerfile FROM line individually — a repo can mix runtimes (Go binary backend + nginx-served static frontend), and neither needs a NODE_OPTIONS pairing even in a repo family where Node pairing was previously relevant elsewhere.",
        "For \"set mem_limit\" issues, always check the Dockerfile's final stage FROM line to decide NODE_OPTIONS pairing — a multi-stage build can produce a non-Node runtime image (e.g. nginx) even when the source is a Vite/Node app, so only the dev/Node-runtime service needs the pairing.",
        "For \"set mem_limit\" issues on a repo with mixed nginx-static + Node-backend + Node-dev-profile services, pairing NODE_OPTIONS --max-old-space-size only with the two Node-based services (skipping it for the nginx static container) while keeping every service's mem_limit env-overridable is a clean, minimal pattern that verifies fully via config resolution (default + `--profile dev`) plus a live up -d on the non-dev services.",
        "For ERR_PNPM_OUTDATED_LOCKFILE bugs in a pnpm workspace with an `overrides` block, verify locally by moving `node_modules` aside and running `pnpm install --lockfile-only` — with `node_modules` present, `pnpm install`/`--frozen-lockfile` silently shortcuts the mismatch check that a fresh Docker build always performs, producing a false \"already up to date.\"",
        "pnpm's frozen-lockfile error message names only the first mismatched importer/dependency, so a lockfile regen fix should always be re-verified with a clean `node_modules` frozen-lockfile install to rule out additional masked mismatches.",
        "When a repo's CLAUDE.md says \"match r3-platform's pinned version for shared deps,\" always diff r3-platform's actual `apps/*`/root package.json against its `templates/*` package.json too — templates can drift ahead (e.g. typescript ^7.0.2) of what the platform's own apps use (^6.0.3), and a scaffolded app can silently inherit the wrong one.",
        "For a compose-generator-style runtime YAML emitter, deriving NODE_OPTIONS's heap ceiling proportionally from whatever mem_limit value resolves (rather than hardcoding it) keeps the two in sync when an operator overrides just the memory cap.",
        "For a github-agent \"hitting GitHub rate limit\" bug, check whether the existing `reRateLimitPrimary`/`classifyRateLimit` regex in forge.go actually matches the exact stderr wording from journalctl — GitHub's GraphQL and REST APIs phrase the same rejection differently (\"already exceeded\" vs \"exceeded\"), and a regex tuned to one silently lets the other fall through to `rateLimitNone`, defeating the gate entirely rather than just weakening it.",
        "For an r3-quest live-verification where `window.location.href` needs interception, Playwright's `defineProperty` override on `window.location.href` throws \"Cannot redefine property\" in Chromium — instead stub the external destination domain via `page.route('https://\u003cdestination\u003e/**', ...)` and assert on `page.url()` after `Promise.all([page.waitForURL(...), click()])`.",
        "For a github-agent \"make sweep X more aggressive\" enhancement, check whether the sweep already exists with tunable interval/threshold config fields before touching code — it's often a live per-host config.yml edit (gitignored) verified via `--diag`, not a code change."
      ]
    },
    {
      "id": "runekeeper",
      "name": "Runekeeper",
      "role": "Database modeling specialist",
      "responsibilities": "Data modeling and storage: schemas, migrations, entities and relations, indexes, query shape and performance, and the integrity rules that keep stored data trustworthy. You guard the shape of everything the platform remembers.",
      "labels": [
        "database",
        "db"
      ],
      "keywords": [
        "database",
        "schema",
        "migration",
        "sql",
        "entity",
        "index",
        "typeorm",
        "relation",
        "data model",
        "dolt",
        "postgres",
        "jsonb"
      ],
      "fallback": false,
      "issues": 138,
      "succeeded": 114,
      "failed": 4,
      "main_attempts": 319,
      "tokens_in": 1713990053,
      "tokens_out": 6558321,
      "cost_usd": 690.5338784500002,
      "last_active": "2026-09-02T19:46:32.782817667Z",
      "memory": [
        "When told \"don't read file X to avoid leaking secrets, use an update script instead,\" treat that as a standing constraint on every tool call for the rest of the task, not just the initial copy — a later ad hoc Read of the destination file for verification is just as much a leak as reading the source would have been.",
        "When two prior \"no completion marker\" attempts on a Docker-cutover issue show real, iterated commits but zero PR, check `docker ps` for a leftover verify stack before assuming any code gap — a healthy container proves the build already works and reframes the whole plan as \"finish the stateful live-verification walkthrough and ship,\" not \"redo the port.\"",
        "For an r3-platform-template app being readied for a shared multi-tenant host, cross-check its docker-compose.yml's container_name/network/PORT variables against `docker ps` + `ss -ltnp` before touching ports — the generic template names collide with sibling apps' already-running containers, and host/internal port coupling via one shared PORT variable silently breaks the container's own hardcoded healthcheck the moment it's overridden.",
        "For an r3-platform NestJS boot-seed issue where `pnpm run dev`/`nest build` are broken by a pinned `typescript@^7`, a throwaway Nest `createApplicationContext` harness importing only the specific platform modules needed (skipping the app's custom-module auto-discovery, which needs the broken build pipeline) compiled via plain `tsc` and run with plain `node` is a fast, real-DB verification path that needs no `ts-node`/`nest-cli` programmatic API at all.",
        "When a design doc's own sections already read as \"data layer → service/controller → frontend,\" mirror that exact structure into the sub-issue dependency chain rather than inventing a different cut — it keeps acceptance criteria traceable back to one doc section per issue.",
        "For a \"scaffold module: entities/migration/contract-types only\" sub-issue in an r3-platform app, verifying a hand-written migration's up/down/up cycle when the app's `typescript@^7` pin breaks `ts-node`/`migration:run` is best done by compiling the migration plus a throwaway verify script with plain `tsc` to a temp dir (symlinking the app's `node_modules` in) and running the output with plain `node` against a disposable Postgres container — no CLI or ts-node involved at all.",
        "When a design doc hedges between reusing an existing timestamp column and adding a dedicated one, decide it at the data-layer sub-issue by asking which *other* modules will later write to that row — mirror-column writes from future phases silently reset any `updatedAt`-based clock.",
        "For a hand-written migration whose entity's date-like columns must be `text`+ISO-transformer (not `timestamptz`) except a bare `@CreateDateColumn()`, cross-check the migration's column types against the entity file line-by-line before verifying — it's easy for the migration to silently use `timestamptz` for a field the entity declares as `text`.",
        "For an r3-quest \"scaffold module: entities/migration/contract types\" issue whose plan doc gives full TypeORM entity code, module.json permission blocks, and a contracts table, the fastest correct path is: scaffold → delete scaffolder CRUD output → transcribe entities/DTO/module.json verbatim from the doc → write one contract file per command/query/event key mirroring the sibling module's exact namespace-with-key pattern → hand-write the migration → verify live against a throwaway Postgres container with a plain-tsc-compiled driver script.",
        "A \"no completion marker\" gap after a full matching report is closed by a cheap re-confirmation (git log/status, a spot tsc run) plus a short new comment and the marker — never a second full implementation pass.",
        "For an r3-quest \"re-confirm a prior commit\" pass, a full acceptance-criteria checklist (fee-service query-key/contract cross-check against the actual installed `@r3/backend` source, a compiled-driver green/red proof of a jest-blocked leak spec, and a delegated live-server HTTP walkthrough of every GET route) is the right depth before trusting a same-titled HEAD commit with no report — don't shortcut to \"looks done.\"",
        "For an r3-quest lifecycle-transition service, verifying a claimed \"pessimistic write lock enforces single-claim\" invariant needs a real concurrent-request test against real Postgres (not just reading the `lock:{mode:'pessimistic_write'}` call) — run the same two-concurrent-request check twice for confidence before trusting the guarantee.",
        "When an acceptance criterion demands proof a specific composite index is chosen (not just \"an index, any index\"), always check row-count-driven planner artifacts first — a near-empty dev table lets Postgres pick a cheaper-looking sibling index of the same leading column, and bulk-seeding + `ANALYZE` before re-running `EXPLAIN` is the fast way to get a representative plan.",
        "For r3-quest phase epics, the scaffold → backend-service → frontend three-way split (mirroring quest-identity's #23/#24/#25) is the default decomposition shape when the plan doc separates entities/migration, service+routes, and pages into distinct sections — reach for it before inventing a different cut.",
        "For a \"geo math library, no DB/DI\" issue whose plan doc provides full reference implementations inline, the fastest correct path is transcribe-verbatim + compile-and-drive-with-plain-node for the pure-function proof, paired with a throwaway-Postgres up/down/up for the accompanying index migration — no service/handler wiring needed when the issue explicitly scopes those out.",
        "When a SELECT column allowlist is built by hand to exclude specific \"fee\" fields, explicitly diff it against every field the downstream view mapper actually reads (not just the excluded ones) — it's easy to accidentally drop a needed, non-fee field (like a payout/money field the view IS allowed to show) that only breaks at runtime, not at tsc.",
        "When a phase epic claims \"not started\" but sibling phases shipped its entity and command handlers, the real remaining work is usually the cross-cutting fan-out layer (typed notification payloads, domain events, batched side-effects) plus UI — cut the decomposition there, not at the already-built data model.",
        "For an r3-quest reopen/notify-fan-out enhancement, calling a cross-module query whose lat/lng/radiusKm args are documented as still-ignored server-side is the right move when scope forbids touching that module — do the bbox+haversine distance filtering client-side in the calling module instead of skipping the geo helper.",
        "When decomposing a phase that has both a request-driven write path and event/cron-driven handlers over the same entities, cut between those two entry-point families rather than by feature — it serializes edits to the shared service file and each half's acceptance criteria stay independently provable.",
        "For an r3-quest \"scaffold module: entities/migration/contract types\" issue whose module.json intentionally has no `frontend` key (data-layer-only scope), confirm the frontend generator's output is byte-identical (`git status`/`git diff` on `apps/frontend/src/generated-module-imports.ts`) after running it — that's the cheap proof the scaffold stayed backend-only as intended.",
        "For an r3-quest push-token/notification-preference sub-issue, `mobileBearerMiddleware` sets `req.user` app-wide before any guard runs, so a bearer-only route needing the caller's identity should read `@CurrentUser()` and manually 401 on absence rather than adding `PlatformAuthGuard` (which targets the cookie/session path and isn't needed since the middleware already resolved the user).",
        "When re-confirming a prior session's uncommitted-report commit, always run `git status` after any scratch/throwaway compile step before trusting it stayed outside the repo — a `tsc` invocation with a miscomputed common-root can silently emit a compiled `.js` beside the real `.ts` source file it imported by absolute path.",
        "For an r3-quest entity with a `@Unique` constraint spanning a nullable column (e.g. `RegionFeeRate(country, stateProvince)` where `stateProvince: null` means \"country-wide\"), Postgres never treats two NULLs as equal, so the plain UNIQUE constraint silently allows multiple country-wide rows for the same country — verify this live instead of assuming the DB enforces the doc's stated invariant, and flag it as a service-layer guard needed in whichever later phase implements the upsert.",
        "When a plan doc's \"Frontend\" section only lists per-giver admin lookup by userId but the backend's existing routes only expose \"get my own row,\" adding one small, clearly-scoped backend GET-by-id route (delegating to already-tested service logic) is preferable to redesigning the admin UI around a missing capability.",
        "For an r3-quest email-invitation feature layered on quest-favorites, \"user already exists\" must mean platform user AND tenant membership (via UserTenantRole lookup), not just a global email match — otherwise a same-email user from a different tenant gets silently favourited instead of invited.",
        "For an r3-quest OIDC-only app (no local email/password form), an issue's literal \"register page renders X, prefills email field\" acceptance text often assumes a local registration form that doesn't exist — the correct adaptation is to move that UX to the first in-app page reached post-auth (e.g. OnboardingPage) and state the architectural reason explicitly in the report, rather than treating it as unmet scope.",
        "When a \"publish() converts field X into timestamp Y\" acceptance line implies X must survive from create/update to a later publish() call, add X as its own persisted column even if the entity bullet list omits it — computing the timestamp early would start the window ticking on an unpublished draft, and this repo already establishes that windows are anchored at publish/assign time (e.g. QuestAssignment.respondByAt), not creation time.",
        "For an r3-quest audience-filter enforcement issue, building one shared SQL predicate method (public OR own OR private-with-trusted-set) that simply has no branch for the excluded category (here 'assigned') is a cleaner defense-in-depth guarantee than an explicit exclusion clause, since it can never leak even if an unrelated future status change makes the excluded category reach the same status filter.",
        "When a re-confirmation session finds the working tree already clean and matching a fully-detailed prior report, the entire job is one tsc run plus a short comment — resist the urge to re-derive or re-verify anything the prior report already covered in depth.",
        "For an r3-quest \"add a boolean flag + toggle + sort-by-it\" enhancement, skip the contracts/commands+handler ceremony entirely when no other module needs to react to the change — an inline request-shape object on the service method (mirroring `update()`'s un-wired pattern) is enough, and reusing the existing `assertGiverOrAdmin` ownership check plus an already-granted permission (no new permission string) keeps the diff minimal.",
        "For a \"boost matching rows to the top of a paginated keyset stream\" ask, prepending a bounded separately-fetched first page plus a permanent exclusion predicate on the main stream (never folding the boost into the keyset predicate itself) keeps existing cursor semantics fully untouched while guaranteeing each row appears at most once.",
        "When a cross-quest aggregate query (like unread counts) needs to know \"which quests does this caller participate in\" but the owning module can't be touched for a new bulk query, persisting the already-resolved counterpart id on each row (mirroring what the domain event already carries) turns it into a single indexed GROUP BY and, as a side effect, naturally fixes the \"stale participant reused after reassignment\" leak that a bare `WHERE questId = :id` scan would have.",
        "For an r3-quest data-layer-only module scaffold, running both `scripts/generate-backend-module-imports.mjs` and `scripts/generate-frontend-module-imports.mjs` (both plain Node, no pnpm needed) and checking the frontend one produces a zero diff is a fast, decisive proof that the scaffold honored a \"no frontend key\" scope boundary.",
        "For an r3-quest \"Payout/LedgerEntry\"-style money-tracking migration, verifying via throwaway-DB insert of a negative `amountCents` row plus a duplicate-UNIQUE-column insert attempt (expecting rejection) alongside the `pg_constraint` no-FK check gives much stronger proof of the plan doc's stated invariants than a bare up/down/up cycle.",
        "When two prior attempts on the same issue both end with \"no completion marker\" but one of them has a real commit, diff that commit against the other attempt and against the pre-issue parent commit first — it can reveal one attempt did all the work and the other did nothing, turning the whole planning task into an audit-and-verify pass rather than a redesign.",
        "For a \"set mem_limit on every docker-compose service\" ask, `docker compose -f \u003cfile\u003e config` resolved-byte-value grep plus a scoped live bring-up of only the non-prod-connected services (skipping any stack whose env wires to a production DB) is enough proof — no need to touch the full multi-container stack.",
        "For a \"set mem_limit on every docker-compose service\" ask whose issue body already gives the target files/services/values in a table, cross-check `git ls-files` for tracked compose files (an untracked host-local override mentioned in a pinned comment is explicitly out of scope) before editing, and if a full-stack live bring-up fails on an unrelated pre-existing build error (e.g. lockfile drift from an unrelated Dependabot merge), don't let it block the report — verify what's buildable (published-image services) live, prove the rest via `docker compose config` byte-value resolution, and file the unrelated failure as its own issue.",
        "For a \"cap every service's memory\" issue across many docker-compose files, cross-check each file resolves with `docker compose -f \u003cfile\u003e config` before touching mem_limit values — a broken `extends:` reference (service removed from the base file in an earlier commit) can silently fail config resolution independent of anything to do with the memory-limit change itself, and fixing it is a small self-contained prerequisite rather than scope creep.",
        "For a \"cap every service's memory\" issue whose repo has zero `.env`/no currently-running containers for the target stack, treat a bare `DB_HOST: postgres` default with no matching service in the same compose file as proof that file targets an external production DB — verify it via `docker compose config` only, and confine live bring-up to genuinely self-contained files (e.g. a dev-only postgres compose).",
        "For a \"set mem_limit on every docker-compose service\" issue, when a full-stack build fails, always first reproduce the same failure on bare HEAD via `git stash` before writing it up — this cheaply proves pre-existing vs. newly-introduced without needing to fix the unrelated issue.",
        "For \"set mem_limit\" issues, live-verifying a self-contained dev-only service (e.g. dev postgres with no external DB) via a throwaway up/down cycle plus `docker inspect` for OOMKilled/HostConfig.Memory is enough proof, while a production stack with an external DB and already-healthy live containers should only be verified via `docker compose config` resolution — never recreated without explicit authorization.",
        "For r3-home's \"set mem_limit on every docker-compose service\" issue, the repo only tracks two compose files (`docker-compose.yml`, `docker-compose.dev.yml`) matching the issue's own table exactly, and the production backend/frontend stack was already live and healthy on the host — verification there was config-resolution plus reading its live `docker stats` against the new caps, while only the self-contained dev-postgres file got a real bring-up/teardown cycle.",
        "For r3-seb-demo's \"set mem_limit on every docker-compose service\" issue, docker-compose.yml had a pre-existing `depends_on: - backend` typo (real service name is `r3platform-backend`) that blocked `docker compose config` outright — confirmed via git stash as independent of the mem_limit change, fixed as a one-line prerequisite, then verified byte-value resolution plus a live dev-postgres up/inspect/down cycle without touching the already-running production containers.",
        "For r3-skill-matcher's \"set mem_limit on every docker-compose service\" issue, the repo's own `postgres` service (unlike sibling repos' production stacks) is defined in the same compose file rather than pointing at an external host, which is the signal that a full live build/bring-up is safe to attempt rather than restricting verification to `docker compose config`.",
        "For \"set mem_limit\" issues, `docker inspect --format '{{.State.Health.Status}} {{.State.OOMKilled}} {{.HostConfig.Memory}}'` in one call is the fastest single proof that a mem_limit was both applied and survived a real container start without OOM.",
        "For r3-teach's \"set mem_limit on every docker-compose service\" issue, the repo tracks exactly the two compose files (`docker-compose.yml`, `docker-compose.dev.yml`) named in the issue's own table, and an untracked `docker-compose.override.yml` (confirmed via git status) is the actual production deploy definition per a pinned comment — scope stayed on the tracked files only, verified via config byte-value resolution plus a live up/inspect/down cycle on the self-contained dev-postgres file.",
        "For \"set mem_limit\" issues where the compose file's container_name/network don't match the currently-running production containers' names, check `docker ps` for the actual deployed stack name before assuming the compose file is unused — it may just be deployed under a different project/container-naming convention than what's in the tracked file.",
        "For \"set mem_limit\" issues, when the issue body already includes a per-service measured-usage table, treat that table as the exact scope boundary (file list + values) and cross-check `git ls-files` against it before editing — no further discovery needed.",
        "For an r3-quest \"reject/flag at create()\" abuse-controls enhancement with three independent settings-backed checks, mirroring the module's own existing `getRespondWindowHours`-style `settings.query.getSystem` try/catch getter pattern per setting (rather than inventing a shared helper) keeps each check's fallback behavior locally obvious and matches the file's established style exactly.",
        "For a Stripe-linked re-authorization/sweeper enhancement spanning a data-owning module and a payments module, decompose along data-layer (schema+cross-module query) → cron/happy-path (external-API + idempotency) → failure-path (notification+retry+terminal-fallback) rather than the two-way split a plan doc's own text suggests, since each of those three is independently a full session's worth of work."
      ]
    },
    {
      "id": "sprite",
      "name": "Sprite",
      "role": "Mobile experience specialist",
      "responsibilities": "Mobile and small-screen experience: responsive layouts, touch interactions, viewport and breakpoint behavior, mobile navigation patterns, PWA/native shells, and mobile performance. You hold the line on every screen narrower than a laptop.",
      "labels": [
        "mobile"
      ],
      "keywords": [
        "mobile",
        "responsive",
        "ios",
        "android",
        "touch",
        "viewport",
        "breakpoint",
        "small screen",
        "smartphone",
        "tablet",
        "pwa"
      ],
      "fallback": false,
      "issues": 97,
      "succeeded": 78,
      "failed": 3,
      "main_attempts": 256,
      "tokens_in": 1259839644,
      "tokens_out": 5055608,
      "cost_usd": 485.15116904999996,
      "last_active": "2026-09-02T20:15:02.401613818Z",
      "memory": [
        "For an app-level middleware issue that reuses a business-module's stateless service class (e.g. a JWT verifier with no injected deps), a plain relative import from `apps/backend` into `apps/modules/\u003cid\u003e/backend/src/...` works and compiles/runs correctly through the dist tree, but the repo's `@modules/*` tsconfig path alias only maps a bare module id to that module's src root — it can't address a file underneath, so don't reach for it for deep imports.",
        "When a repo's e2e-testing toolchain is provably broken (ts-jest vs pinned TS major version), write the jest spec anyway for future-readiness but verify live via the established compiled-app-boot workaround, and delegate that live HTTP+DB verification work to a subagent since it's inherently iterative and exploratory.",
        "When decomposing an epic whose frontend slices will later be wrapped by a separate mobile-shell phase, write the small-screen criteria into those child issues now — retrofitting viewport/touch-target fixes after the pages ship costs more than specifying them up front.",
        "For a \"pins if count\u003c=N else clusters\" viewport query, fetching N+1 rows and checking length beats a separate COUNT query — same correctness, one less round trip.",
        "For a \"wire an existing pure geo/jitter helper into a view mapper\" enhancement, always sanity-check the helper's hash-seeded behavior against short test-fixture ids before trusting a \"passes but offset looks small\" result — a `hash \u003e\u003e\u003e 16` style term can silently zero out for short strings while working correctly for real UUID keys.",
        "MUI v9 Slider ships its own invisible `::after` hit-target pseudo-element (default ~42px, documented in MUI's own source comment) separate from the `::before` used for the box-shadow ring — when a touch-target acceptance criterion asks for ≥44px on a Slider thumb, bump `\u0026::after` specifically rather than adding a new `::before`, which would silently clobber MUI's hover/focus ring instead of fixing the hit area; the analogous trap for a `select` `TextField` is that `slotProps={{ htmlInput }}` targets the hidden `aria-hidden` native input, not the real tappable `.MuiSelect-select` div, so min-height/touch-target styles there are a no-op.",
        "When a frontend page imports react-leaflet/leaflet inside a module living outside apps/frontend's own directory tree, add explicit tsconfig `paths` entries (pointing bare `leaflet`/`react-leaflet` specifiers at `apps/frontend/node_modules/...`) — plain node_modules resolution never finds them otherwise, matching the pattern already used for every other external frontend dep in this repo.",
        "When decomposing a mobile phase whose plan doc predates the backend it targets, diff the doc's screen list against the actual controller routes first — stale email/password auth screens against an OIDC-only backend is the single most expensive decomposition error.",
        "For an Expo-shell scaffold task, resolve real dependency versions by scaffolding a disposable `create-expo-app` project under the target Node version and mirroring its resolved package.json into the real app, rather than trusting a design doc's version pins, which are usually stale by the time the doc is implemented.",
        "For an Expo/Metro i18n build-time merge pipeline, load the generated JSON via `require(...)` wrapped in try/catch rather than a static `import` — it keeps `tsc --noEmit` clean whether or not the generated files exist yet, without needing a committed stub in a gitignored directory.",
        "For a \"map doesn't center on user location\" bug, check whether a sibling page in the same feature already has a working geolocation-resolution helper before writing new geolocation code — the fix is often just extracting and wiring that helper into the map page, plus confirming the backend's location-persistence write path is actually called from somewhere.",
        "For an Expo mobile \"session core\" issue whose acceptance criteria include live proof that a revoked refresh token produces a clean 401 (not a hang), reuse the repo's mint-a-refresh-token-row-directly technique paired with the same OpenAPI-doc-generation container trick (booting the compiled Nest app's AppModule via a scoped require()) already used for type generation — both piggyback on the same running backend container and avoid needing a mobile simulator.",
        "For a mobile-auth phase whose \"known blocker\" write-up assumes the agent has Keycloak realm-admin access, always probe for it early (client_credentials grant, then anonymous Dynamic Client Registration) — if both fail, implement the backend-side env-var audience fallback instead of the Keycloak-mapper option, since it's the only one verifiable/shippable without admin access, and document the manual provisioning step as a follow-up rather than blocking the whole issue.",
        "For a mobile location-permission gate, pair `useFocusEffect` with an `AppState` 'active' listener — toggling permission in the OS Settings app backgrounds/foregrounds the app without ever blurring the screen in React Navigation's sense, so focus-only re-checks silently miss the most common \"denied → Settings → granted\" recovery path.",
        "For a \"server two-tier viewport + client visual clustering\" map feature (react-native-maps + react-native-map-clustering), use the clustering library's own `cluster.onPress` (fitToCoordinates over real leaf markers) for its local visual clusters, and reserve a custom animate-to-centroid handler only for the server's separate pre-aggregated `mode:'clusters'` tier — conflating the two loses the library's more precise default behavior.",
        "When decomposing a mobile phase whose slices each touch the root `_layout.tsx` (push setup, location hook, cache provider), chain them serially rather than in parallel — the shared-file contention costs more than the lost concurrency.",
        "When delegating live-DB verification to a subagent that needs to dodge an ESM/CJS wall (like jose@6 under Node 18) by stubbing platform packages, always re-check the real node_modules symlinks survived intact afterward — a stub aimed at a scratch dir can land in the real tree and silently break the whole repo's type-checking.",
        "For quest-ratings-style batched reputation enrichment, the \"one call per list render\" criterion is best confirmed by finding the controller-side batch method (e.g. `batchGiverReputation`) and checking it takes an array of ids rather than by scanning the frontend for a fetch-in-a-loop pattern.",
        "When an r3-quest issue's requested change targets `../github-agent/config.yml` (a live, untracked, mode-600 orchestrator config shared by the whole fleet) rather than app code, treat it as an architectural-boundary case by default — verify the rebuild_command executor's blocking-exec + post-rebuild health-gate model in github-agent's own source before assuming a simple config append is safe, since a long-running foreground process (like `expo start --tunnel`) chained onto it would hang every future rebuild.",
        "For an Expo push-notification device-registration feature, gate the locally-persisted \"last registered token\" write on PATCH success (not on token fetch) — it makes a pre-login foreground attempt (no session to attach to) naturally retry on the mandatory post-login run instead of needing separate pre/post-login state tracking.",
        "When verifying a \"no completion marker\" retry, regenerating build-time-merged i18n bundles (e.g. via a repo's generate-mobile-i18n script) before typechecking/exporting is necessary to actually confirm module-sourced translation keys resolve, not just that they exist in source locale files.",
        "For a mobile foreground-location-ping feature layered on an existing one-shot permission-gate hook, keep the throttle as a pure `(position, lastState, now) -\u003e {shouldSend, nextState}` reducer so both a synthetic-sequence unit test and the stateful watchPositionAsync hook itself thread the exact same state machine, and gate the ping's enablement on domain state (e.g. \"has an adventurer profile\") already fetched by the mounting layout rather than adding a second fetch.",
        "For a react-query offline-persistence enhancement, prefer `PersistQueryClientProvider` over hand-calling `persistQueryClient`, and drive the offline banner from `onlineManager`'s own subscribable state (via `useSyncExternalStore`) rather than a second independent NetInfo subscription — it guarantees the banner can never disagree with what's actually paused, and a plain in-flow (non-absolute) banner element sidesteps the whole class of stacking-context/overlap bugs by construction.",
        "For a \"repo missing rule\" doc-fix issue, grep every rule file (CLAUDE.md, AGENTS.md, .cursor/rules/*) for the missing keyword first — an empty grep across all of them is the fastest confirmation the gap is real and shows exactly which files need the new rule woven in for it to actually be seen at the right decision points.",
        "For a create-form enhancement whose new mode requires a value only accepted by a *later* endpoint (not the create endpoint itself), chain create+that-follow-up-call in one submit and keep the created id in state so a failed second call can retry without re-submitting the whole form.",
        "For mobile-parity issues that ask to gate a screen \"the same way as an existing web permission,\" check whether that web permission is actually role-scoped (grep the platform's role-seed service) — mobile has no granular permission system, so the equivalent gate is usually the matching onboarding-status role flag (e.g. `hasQuestGiverProfile`), not a new mobile permission mechanism.",
        "When a mobile enhancement issue explicitly names its own prerequisite screen as not-yet-landed, a fast grep-confirm of that screen's current absence is the whole job — don't attempt partial implementation against a screen that doesn't exist.",
        "For mobile favorite/action-toggle issues gated on a not-yet-existing screen, confirm the screen's absence and the gating epic's open/closed state before doing anything else — that single check is the whole job.",
        "For r3-quest quest-detail entitlement UI (web or mobile), the frontend gate should mirror the backend's `isEntitled` check (`viewerUserId === questGiverUserId || viewerUserId === assignedAdventurerUserId`) directly rather than reusing a broader `isTerminal`/status set, since acceptance criteria for \"hide when navigation is meaningless\" often name only a subset of terminal states (e.g. cancelled/expired, not completed).",
        "When a mobile enhancement issue's own PR was closed without merge and contained only prior-session bookkeeping files (no code diff), that's a strong signal to re-verify the original blocker state rather than assume anything changed.",
        "For gh-180-style re-escalations, checking whether the previously-opened PR was merged or closed-without-merge is the fastest signal for whether anything changed since the last blocked verdict.",
        "For an Expo Router nested-route addition (turning `[id].tsx` into `[id]/index.tsx` plus a new sibling file), always regenerate `.expo/types/router.d.ts` via a brief `expo start --offline --non-interactive` pass before trusting a `tsc --noEmit` failure on the new route's `router.push({pathname: ...})` call — `export` never touches that file.",
        "For a web notification-preferences page whose backend endpoints and mobile hook already shipped, live-verifying with Playwright route-mocking of just `/api/auth/me` plus the feature's own GET/PATCH endpoints is sufficient — but any sibling page reached via in-app navigation (e.g. ProfileSettingsPage) needs its own API calls (profile fetches, onboarding-status, tenants, ui-preferences) mocked too, or it silently redirects/hangs and produces a false \"button not found\" result unrelated to the feature under test.",
        "For an r3-quest issue needing new frontend npm packages, the Node-22-Docker `pnpm install` workaround can hit pnpm 11's `minimumReleaseAge` supply-chain gate if a dependency's semver range resolves to a same-day release — pin to an older minor instead of accepting the auto-generated `pnpm-workspace.yaml` policy exclusion.",
        "For an r3-quest github-agent re-escalation whose thread shows only the bot's \"no completion marker\" note, checking out the parent commit's tree in place and diffing raw tsc error counts is the fastest way to prove a suspiciously large error count is pre-existing repo noise rather than a regression from the branch's already-landed commit.",
        "When a fully-correct, fully-reported implementation still shows \"no completion marker\" twice in a row, verify the marker-printing step itself (same-turn continuation after `gh issue comment`) rather than assuming a code gap — the enhancement.md anti-pattern of ending the turn right after posting the report is a real, recurring failure mode independent of code correctness.",
        "For an optimizer prompt-tightening digest, cross-referencing the target repo's own metrics-YYYY-MM.json archive against the cited issue numbers' actual attempt records is a much stronger evidence source than the digest's narrative — it directly shows which attempts burned tokens without a marker versus which succeeded, letting you scope the fix to the real failure mode instead of the digest's guess.",
        "For an r3-quest mobile issue whose own body cites a still-open prerequisite epic, re-derive whether the requested delta actually needs that epic's scope (e.g. lifecycle actions) rather than trusting the stated dependency — a read-only display feature against already-shipped GET endpoints is often unblocked even when the epic isn't done.",
        "When an epic's plan doc prescribes an expo-router route-group restructure, check whether the existing routes are push-notification deep-link targets before accepting the move — `href: null` tab gating usually delivers the same role-scoped UX with none of the deep-link breakage.",
        "When two straight escalation attempts on the same mobile feature end with only \"no completion marker\" bot comments and no executor report, check for \"recovery commit (interrupted run)\" commits on the branch — they're the tell that the implementation is already complete and the failure is a mid-session interruption before the report/marker step, not a code gap.",
        "For a mobile Checkout/Portal parity issue whose acceptance criteria say \"refetch on focus/return\" after opening an external Stripe URL, `expo-web-browser`'s `openBrowserAsync` promise resolving on dismissal is itself the reliable completion signal — await it and refetch immediately, then add `useFocusEffect` only as a secondary safety net for returning to the screen by other paths, rather than reaching for the AppState-listener pattern used for OS-Settings-permission flows (which don't produce an awaitable completion signal).",
        "For a Stripe Connect onboarding round-trip on mobile, mirror the existing OIDC `promptAsync`/`redirect.tsx` pattern exactly — `openAuthSessionAsync(url, scheme://path)` reliably intercepts the return without any OS-level deep-link race, and a dedicated auto-discovered root-level route (no `_layout.tsx` needed) is the natural landing pad for a post-redirect polling step.",
        "For an r3-quest mobile \"wire photo upload to POST /attachments/upload\" issue, always check whether `PermissionDiscoveryService` (auto-assigns newly-discovered `@RequirePermission` strings only to `admin`) has left the adventurer/giver roles without `attachments.create` before building the upload UI — it's a recurring, fixable gap via `quest-roles-seed.service.ts`'s `PLATFORM_PERMISSIONS` array, not a blocker.",
        "For an r3-quest giver-actions detail screen, share a single inline reason section (state keyed by which action is pending) across dispute/cancel rather than building near-identical sections per action — halves the UI code and keeps the \"disabled while reason is empty\" rule in one place.",
        "For an r3-quest mobile \"publish → payment retry\" design that the issue text says should re-call POST /quests/:id/publish, always check the backend's actual status guard first — publish() only succeeds while status==='draft', so persisting the client_secret locally at publish time (not re-fetching) is usually the only in-scope fix once \"no new backend endpoints\" is a hard constraint.",
        "For an r3-quest mobile \"invites + rating + reputation\" enhancement, a single shared reputation hook (live-fetch fallback) plus one presentational badge component covers every surface cleanly — some surfaces already carry batch-enriched reputation fields (no fetch needed), while others (a detail screen's dynamically-resolved counterparty) genuinely need the live-fetch hook, and both should render through the same component so the \"New\" threshold rule lives in exactly one place.",
        "For an epic whose plan doc lists more workstreams than the 2–6 decomposition ceiling allows, group the small read-only verification passes together and give each oversized child an explicit pre-chosen split seam in its body, so the next agent splits cleanly instead of half-landing.",
        "For a NestJS rate-limiting enhancement, verifying the guard's actual 429+Retry-After+tracker-isolation behavior via a throwaway supertest-driven mini Nest app (mirroring the real route's exact guard/decorator config) is far more convincing than reading the decorators, and is cheap since ThrottlerGuard's default in-memory storage needs no DB.",
        "For an admin-only backend+UI enhancement issue that pre-authorizes a backend/UI split, treat that authorization as license to file the UI as a single follow-up child issue rather than full multi-issue decomposition — implement and fully live-verify the backend layer in the same session it's scoped for.",
        "For an admin console page whose tsc run shows implicit-any cascades starting from \"Cannot find module 'react'\", always diff the parent commit's tsc line count in place before treating it as a new regression — it's frequently a repo-wide pre-existing pattern hitting unrelated modules too."
      ]
    },
    {
      "id": "herald",
      "name": "Herald",
      "role": "CQRS \u0026 event patterns specialist",
      "responsibilities": "Command/query separation and event-driven architecture: command and query bus contracts, handlers, domain events and subscribers, sagas, projections, and the messaging boundaries between modules. You keep commands, queries, and events clean, explicit, and decoupled.",
      "labels": [
        "cqrs",
        "events"
      ],
      "keywords": [
        "cqrs",
        "command bus",
        "query bus",
        "event",
        "handler",
        "saga",
        "projection",
        "subscriber",
        "dispatch",
        "messaging",
        "domain event"
      ],
      "fallback": false,
      "issues": 76,
      "succeeded": 63,
      "failed": 3,
      "main_attempts": 182,
      "tokens_in": 926942809,
      "tokens_out": 3742661,
      "cost_usd": 374.0693246500001,
      "last_active": "2026-09-02T11:41:16.585704787Z",
      "memory": [
        "In r3-platform, `EventRegistryService.getAll()` (from `libs/backend-common/src/modules/events-registration`) is the ready-made declared-event catalogue for any \"trigger picker should list events even before they've fired\" ask — union it with an existing event-store-observed query rather than replacing it.",
        "For an \"invoke_command should discover commands like emit_event does\" ask, `QueryBusService.listHandlerKeys()` filtered on `.includes('.command.')` (matching the `\u003centity\u003e.command.\u003cverb\u003e` convention already used repo-wide) reliably separates commands from queries with zero new plumbing — verified against every existing `static readonly key` in the codebase before trusting the filter.",
        "When an epic-labeled issue's own body explicitly permits direct implementation for limited scope, and the ask reduces to one architectural chokepoint (e.g. a QueryBus's single execute() method), implement directly rather than filing sub-issues — decomposition is for genuinely independent deliverables, not a default triggered by the epic label alone.",
        "For r3-platform's `apps/backend` jest, `--testPathPatterns` (plural, non-standard) is silently ignored and runs the full suite instead of filtering — harmless when everything passes, but don't rely on it to scope a targeted re-run; use `--testPathPattern` (singular) if a true filter is needed.",
        "When a CQRS UI needs a contract's shape at runtime, TS `Request`/`Payload` namespaces are erased — pair an optional static schema on the contract base (declared, covers never-fired contracts) with observation of persisted traffic (covers undeclared ones), and for commands persist only the request's field *names* since request values routinely carry secrets.",
        "When a docker-compose healthcheck bug report cites a container that's actually running and reachable via curl, check every compose file that could be driving that container (including gitignored/host-local overrides with no git history) for a stale duplicate healthcheck block, not just the tracked compose files — a prior fix can diverge silently between tracked and untracked copies of the same override.",
        "When a permission flag turns a query handler's masking decision caller-dependent, any existing response-level cache keyed without that permission must be restructured to cache the permission-agnostic raw data and apply masking at read time — caching the already-masked/unmasked response lets whichever caller populates it first dictate visibility for everyone else.",
        "When an optimizer digest's cited \"top-token\" example issues each dissolve into already-fixed unrelated bugs, don't stop at debunking — re-run the digest's own query (pull every issue in the window from metrics.json, not just the cited ones) to check for a genuine, narrower gap the digest missed entirely.",
        "When an issue's acceptance criteria call for \"fully green\" tests but some specs fail after a large refactor, git-worktree-mounting the parent commit's same subtree into an already-built test image and re-running the identical spec is a fast, conclusive way to prove a failure is pre-existing rather than a regression, without a second full rebuild.",
        "When a CQRS query needs cross-module data that lives in another module's table (e.g. a cluster-summary reading etl_executions from etl-nodes), check for an existing same-file precedent of raw SQL against the shared control DB via `repository.manager.query()` before reaching for a new query-bus key — it's often already the established pattern for this exact class of read.",
        "For a CQRS-style remote-execution split (orchestrator ↔ off-box agent node), the clean seam is a payload-scoped port implementation (e.g. `LeaseRunControlAdapter implements RunControlPort`) that serves reads from the lease and buffers writes in memory for the caller to attach to a completion report — the node never gets bus or DB access, only what the lease payload pre-resolved.",
        "For a \"record clip, upload, then dispatch playback via Home Assistant\" enhancement, query the live instance's `GET /api/services` for the actual field names/selectors (e.g. `music_assistant.play_announcement`'s `url`/`announce_volume` vs `media_player.play_media`'s `media_content_id`/`announce`/`extra.volume`) rather than reconstructing them from memory — the exact keys and value ranges (e.g. 1-100 vs 0-1) differ by service and are easy to get subtly wrong.",
        "For a \"add markers/indicators driven by an events API\" enhancement, split cleanly into a fetch+bucket hook (mirroring the closest existing data hook's refresh/error pattern) plus a pure per-cell render helper (dedupe/cap/color logic) — keeps the timezone-sensitive bucketing logic isolated and testable from the cap/dedupe display logic.",
        "A github-agent \"ended without completion marker\" resume on an already-fully-matching commit+report needs only a quick build re-check plus a short confirmation comment — no re-reading of the diff for new work.",
        "When decomposing a \"rewrite as a CQRS module\" epic, put the integration layers on parallel branches off the settings/config sub-issue rather than one linear chain — connector-style integrations (photos/weather/calendars) share no surface with the stateful device gateway and only rejoin at the UI port.",
        "When a CQRS gateway epic ports a REST-era read path, check whether the legacy code used a workaround (template rendering, polling) that the new persistent transport makes unnecessary — say so in the sub-issue, or the port will faithfully reproduce the workaround.",
        "For an in-process WebSocket reconnect/backoff test, keep the test's shortened base delay comfortably above the poll interval — a too-fast reconnect can complete between polls and hide the intermediate state entirely.",
        "For a \"port X onto the new gateway, replacing hack Y\" enhancement, always live-verify the new read path against the old one on the real backing service before reporting — it surfaces both regressions and cases where the new approach is more accurate than the legacy workaround, which is worth documenting rather than just matching.",
        "When decomposing a CQRS port of several read+write surfaces, split on the read/write seam and make the read side's projection query explicitly the shared registry later write-side and sibling-feature issues consume, so entity allow-lists have exactly one owner.",
        "When designing a per-domain settings-selected provider seam, split it into a fully generic `ConnectorRegistry\u003cTProvider\u003e`/`RefreshableCache\u003cT\u003e` pair (no domain knowledge) versus the domain's own provider interface/impl/factory subclass/orchestrating query service — the generic pair is what sibling domains actually reuse, everything else stays domain-local.",
        "When porting a pure-parsing library function (ICS/RRULE expansion) into a CQRS query service, keep the pure parse+expand logic in a framework-free module reusable by both the connector-registry provider and the query service, and only put per-key caching/error-state/settings-resolution in the query service — this keeps trap-preserving logic (e.g. exact recurrence/timezone edge cases) testable without any DI or settings mocking.",
        "When a QueryBus's `emit`/`registerEventHandler` only supports boot-time class-decorated subscribers with no per-caller subscribe/unsubscribe surface, the clean pattern for a per-request stream (SSE) is two cooperating `@EventHandler` classes on the same event — one that detects/emits the domain fact, one dedicated bridge that re-subscribes locally per caller — rather than trying to make the bus itself support ad hoc subscriptions.",
        "For an r3-domotic write-side command explicitly required not to embed a settle/reconcile wait (unlike DeviceCommandService's waitForNextState pattern), the domain event the command emits on success should be a bare \"this changed\" signal carrying no new state — the caller is expected to re-read the query side off that event or the generic entityStateChanged event instead.",
        "When a QueryBus command's payload can carry a Buffer in-process (no serialization boundary), model even a binary-upload endpoint as a bus command — only genuinely streaming-out routes need to stay raw controller routes.",
        "When a CQRS query's handler already exists with no HTTP route (GetWeatherQuery/GetCalendarEventsQuery here), the controller addition is a pure thin pass-through — spend the verification budget on proving the underlying service/external-API contract still holds (e.g. a live call to the real upstream API) rather than re-testing plumbing that's already unit-tested.",
        "For a CQRS module whose controller-surface acceptance criteria send fields from two separate command contracts (profile update + opt-in) to a single PATCH route, fold both contracts' fields into one request DTO and have the controller call both service methods conditionally — don't invent an extra route the design doc's table doesn't list.",
        "For a \"shared exit-path\" refactor issue (multiple state-machine branches must funnel through one private method), grep-proving the single-writer invariant (`grep -n \"\u003cthe mutation\u003e\"` cross-checked against `grep -n \"\u003cthe shared method name\u003e\"`) is a cheap, literal way to satisfy an acceptance criterion that demands exactly that proof.",
        "When a \"make this typed\" enhancement touches a shared helper method called from many call sites, grep every call site up front and classify each against the acceptance table before editing — it surfaces the one row (here, auto-approve needing a second recipient) that the shared method's existing single code path can't satisfy without an additive call from the specific caller that needs the extra fan-out.",
        "When acceptance criteria list response fields (e.g. level/star average/completed count) that trace back to a not-yet-built sibling module (ratings/reputation), the correct CQRS move is to ship the field with an honest null/0 placeholder and a follow-up issue — not a reverse-dependency query into a higher-layer module just to fabricate real-looking data.",
        "When a lifecycle event's payload carries only a pre-transition boolean flag (not the counterparty's user id), it's safe to fetch the counterparty id from the current entity state via a cross-module query, since only the *status* is ambiguous post-transition — the id fields the flag was designed to protect against re-deriving are typically left untouched by the transition itself.",
        "For a \"second independent consumer of an existing domain-event stream\" enhancement, resolving which user-id fields the payload lacks by re-querying the emitting module's own find-by-id contract (rather than reaching into its tables) keeps the new consumer decoupled while still letting it mirror the original consumer's exact audience logic.",
        "For a \"unified login/register\" ask where separate login/register endpoints already exist, the CQRS-clean move is one client-side form that swaps mode based on the specific error codes (ACCOUNT_NOT_FOUND / EMAIL_ALREADY_REGISTERED) rather than adding a combined backend endpoint.",
        "For a github-agent resume whose branch HEAD's diff and posted report already fully match the issue, grep the re-run type-check output for just the touched file paths rather than trusting a raw error-count delta against the report's own count — repo-wide pre-existing noise shifts the total between runs.",
        "For an r3-quest \"implement the plan-doc-specified algorithm verbatim\" service task, live-testing the DELETE/clear path can surface an intentional but surprising documented edge case (a find-or-create anchor row makes a cleared override resolve as source:'subscription' not 'default') — worth calling out explicitly in the report as \"not a bug\" rather than silently patching it.",
        "A \"report posted, no marker\" resume needs only the cheapest applicable gate re-run (here, tsc --noEmit) before posting a short confirmation and closing the loop — re-deriving the full live-verification is wasted effort when the original report already did it.",
        "When a decline/withdraw/expire notification path assumed \"reopened\" always means \"back in the pool,\" adding a new terminal (cancel) outcome to that shared exit path requires auditing every post-transaction notify/fan-out call site for that assumption, not just the transition logic itself.",
        "When decomposing a payments/Stripe epic, give the webhook infrastructure (raw-body mount, signature verification, idempotency gate, dispatcher map) its own sub-issue ahead of any business branch — it's independently verifiable via CLI event replay and is the extension point later phases add map entries to.",
        "For a CQRS thread UI needing per-message sender attribution, prefer enriching the existing query's Response with a small `participants: Record\u003cuserId, displayName\u003e` map resolved once per request (not one profile lookup per message) via whatever cross-module profile-lookup contract the codebase already established for this pattern, rather than adding a new frontend-facing endpoint.",
        "For a push-notification handler that already parameterizes its deep-link path per category, a new event-driven category whose payload carries the resolved recipient (not just a status flag) needs no audience-inference query — only the title lookup — which is a useful tell for how much of the existing handler's machinery a new category actually needs to touch.",
        "For a Stripe-webhook-infrastructure sub-issue, a throwaway standalone Node script that reconstructs the exact middleware chain (raw-capture mounted before a stand-in json() parser) and fires real HTTP requests at it is a disk-safe way to satisfy a \"verify against the running container\" acceptance criterion when a full docker rebuild is blocked by host disk pressure.",
        "For a Stripe-webhook dispatcher enhancement adding new event-type branches, wrap each branch's row-update + domain-event-queue in one queryBus.withTransaction/tx.queueEvent call (mirroring the entity-mutating command pattern elsewhere in the same codebase) rather than a bare repository.update — keeps the emitted fact strictly conditional on the DB write actually committing.",
        "For an \"event fires twice with different statuses across a webhook-mediated multi-step transition\" design question, re-emitting the same event type at each genuinely distinct state (not inventing a parallel event) is usually the right call — it's not a double-fire if the payload differs and each emission represents a real, separate fact.",
        "When decomposing a payments epic whose plan doc prescribes event-driven subscribers, grep the emitting module for an existing imperative `queryBus.execute` of the same effect first — the sub-issue's real job is often choosing one owner, not adding the subscriber.",
        "When decomposing a webhook-forwarding epic, make a child's acceptance criteria assert on the cross-module forward's *call count* — that is what actually proves a \"the idempotency gate upstream means the downstream module needs no gate of its own\" design property, rather than leaving it as an untested assumption.",
        "When an issue's own step-by-step description says \"if status !== X, no-op\" but its acceptance criteria also require a same-handler retry to resume mid-sequence, treat the acceptance criteria/test list as authoritative and read the guard as \"any status other than the valid entry points\" (e.g. the original state and the next state reached partway through), not literally the single state named in prose — the retry path is unimplementable under the literal reading.",
        "When an enhancement issue explicitly says \"pick one owner and say so, whether the imperative call is removed or left in place,\" prefer removing the imperative call once the event subscription covers every emission site — it's usually strictly redundant and its ad hoc gating is often the source of the very gap the issue is fixing.",
        "For a cron-driven reconciliation/mismatch-alerting enhancement whose plan doc says \"notify admins\" but the platform has no group-notification-by-permission primitive, resolving the target audience via a direct join on the permission the module already declares (not a hardcoded role name) keeps the notification semantically tied to the same access control the feature already enforces elsewhere.",
        "When a github-agent escalation shows repeated \"no completion marker\" with no report and the diff on disk already satisfies every acceptance criterion, check the *live container's* health before assuming the executor failed at implementation — a stale image built in the narrow window between two commits can crash-loop on a DI gap the very next commit already fixed, burning the executor's budget on a live-verification step that looks like a real bug but isn't.",
        "For a CQRS webhook-forwarding branch that fans out into several distinct local-state transitions (checkout/created/updated/deleted/invoice.paid/invoice.payment_failed) driven by the same forwarded command, a stateful in-memory mock DataSource (Map-keyed rows, mutated by each `withTransaction`/`save` call) is worth building as a one-off per-describe-block fixture — the shared single-value-per-test repository mock used by the rest of the file can't thread state across a multi-event sequence test, which is exactly what full-lifecycle acceptance criteria for this pattern require.",
        "For a nightly grace-period sweeper enhancement, a targeted read/write round-trip against the live dev DB (insert throwaway boundary-case rows with no FK dependency, run the exact WHERE clause, verify, then delete) is a fast, low-budget substitute for a full docker rebuild + cron-trigger live verification when the acceptance criteria hinge entirely on one SQL comparison's correctness."
      ]
    }
  ]
}