Project-Aegis

Diagnose and design the fix for the "change didn't take effect" access-bug class — a removed user still sees the data, a revoked role still works, logout doesn't end the session, a plan change still shows the old tier, a deleted item stays visible: inventory every place the old authority survives (server session records, JWT/token claims until expiry, client-side stores and data caches, server/CDN caches, live realtime subscriptions, database session context, search indexes, signed URLs), locate which holds the stale copy, design the invalidation or forced refresh per surface against a stated revocation-latency bound (deny direction first: revoked access must actually revoke), and verify with before/after tests that access changed. Composes caching-strategy-designer, realtime-subscription-architect, plan-entitlement-architect, share-link-access-architect, rls-policy-auditor. Do NOT use to design a cache, author the permission matrix, or when access never worked — this owns changes that failed to propagate.

Decide cloud platform, abstraction rung, and deployment posture cloud-neutrally — gather requirements FIRST (compliance/residency, latency/regions, availability, cost, team maturity, existing estate), shape the provider-neutral logical architecture, THEN pick the highest abstraction rung the workload tolerates (IaaS/VPS → container-PaaS → managed-Jamstack/SSR → Postgres-BaaS → edge/serverless → hyperscaler), a provider within it (modern managed platforms e.g. Vercel/Render/Supabase/Cloudflare, or a hyperscaler AWS/Azure/GCP), and per-capability managed-vs-self-hosted posture — with tradeoffs, exit costs, and an ADR handoff. Ties to isolation, cost, and ops maturity, never fashion. Use when asked which cloud, provider, or platform tier to use, whether to migrate, managed-vs-self-hosted, or single-vs-multi-cloud. Do NOT use to MAP a decided provider to services (aws-/azure-saas-architect), system structure (architecture-designer), tenancy (saas-platform-architect), or IaC review (iac-reviewer).

Design a SAFE dynamic-testing (DAST) harness against a RUNNING application — the safety harness is the deliverable, not an attack method. Mandates EXPLICIT WRITTEN AUTHORIZATION before any run (scope, target, window, blast radius recorded — composes human-approval-boundary); staging/non-production targets only unless prod is explicitly authorized; rate/impact limits so it never DoS-es the target; no destructive probes without separate sign-off; data-handling; and the run/result contract. Fail-closed: no written authorization → no run. It DESIGNS the harness; it is NOT a penetration-testing playbook and does not enumerate exploits (out of scope). Use when planning authorized dynamic testing of a running app or building the safety harness around it. Do NOT use to enumerate exploits (out of scope), define WHAT to test (threat-modeler), test tenant isolation (multi-tenant-security-tester), or scan static code (security-scan-orchestrator).

Design HOW a SAST suite is RUN over a repository — category-level analyzer selection (not a named vendor), ruleset/config management, baseline + diff-scanning (gate NEW-since-baseline on PRs vs full scans), incremental-vs-full strategy, a GOVERNED false-positive suppression list (never silent inline muting), and CI integration. Designs the RUNNING of SAST and feeds the whole-repo aggregator (security-scan-orchestrator, in-batch); the INTERPRETATION of findings (true/false-positive, ranking, the suppression VERDICT) is static-analysis-reviewer's (yield). Fail-closed: a scan that errors, times out, or skips a language is a REPORTED GAP, never a silent pass. Use when standing up or tuning SAST, designing baseline/diff scanning, or governing FP suppression. Do NOT use to triage findings (static-analysis-reviewer), aggregate a whole-repo scan (security-scan-orchestrator), or scan dependencies (supply-chain-security-reviewer).

Orchestrate a whole-repo security scan and aggregate it into ONE prioritized report — coordinate the static suite (SAST + dependency/SCA + secret + IaC/config scanning), normalize every scanner's output into one finding schema, and route it. It RUNS and AGGREGATES; it does NOT triage findings (finding TRIAGE is static-analysis-reviewer's — yield) and NEVER fixes, opens PRs, or changes settings — every action is handed to a human. Tool-agnostic (scanner CATEGORIES, not one vendor's CLI). Fail-closed: a scanner that errors or cannot run is a REPORTED GAP, never a silent clean pass. Use when asked to security-scan a whole repo, run the scan suite, or aggregate multi-tool findings. Do NOT use to triage findings (static-analysis-reviewer), judge dependency risk (supply-chain-security-reviewer), design the SAST run (sast-orchestration-designer), or test a running app (dast-safety-harness-designer).

Design the governed operating environment an AI agent runs inside — the harness: ONE server-side mediation point every model/tool call crosses; identity from credentials (never from model-supplied payload), propagated; a deny-by-default pre-flight ladder (authenticate → authorize → entitlement → budget → input policy) BEFORE the model runs, each rung fail-closed; a CLOSED tool/provider registry (unknown capability fails, never improvised); instructions as server-side versioned artifacts no untrusted party can override; a fail-closed audit write — what cannot be recorded does not execute. The AI-specific harness atop command-gateway-architect's mediated path, enforcing agent-authorization-matrix's policy. Use when wiring an agent into a runtime or when model calls run ungoverned. DESIGNS the harness; its attack review belongs to agent-tool-safety-guard, agent-containment-reviewer, prompt-injection-defender. Do NOT use for loop bounds/stops (agentic-loop-designer) or context content (model-context-designer).

Design an agentic loop's shape and bounds — single-shot vs agentic as an EXPLICIT up-front decision (never default to a loop); clamped iteration ceilings; TYPED retryability (a policy rejection is TERMINAL, never retried; a transient failure is retried once on IDENTICAL input (reproducibility key) to classify flake vs deterministic); honest terminal states (an empty result is a legitimate stop, never forced into fabricated output); plan-act-observe-reflect with a defined stop. A loop needs an honest way to stop, including the honest empty set. Consumes iteration/cost caps from ai-cost-guardrail-designer (budget is an input; this owns loop SEMANTICS/stopping); designs the structure agent-failure-recovery plugs into; the loop runs INSIDE agent-harness-architect's harness. Use when deciding whether a task needs a loop, designing retry/stop behavior, or when an agent loops unbounded or fabricates on empty. DESIGNS the loop; manipulation attack review belongs to agent-goal-hijack-defender and ai-threat-modeler.

Design what enters and leaves a model's context window — a curated diet, not open access: context assembled SERVER-SIDE under hard token/size caps; every input passes a CLOSED schema; secrets/PII/raw payloads minimized or carried on a transient never-persisted channel with the persisted-vs-transient split explicit; what the model saw RECONSTRUCTIBLE afterward; exclusions designed and documented, never accidental. The context window is a supply chain — an unverified input is an unverified output. Distinct from agent-startup-context-gate (session-START loading; this is runtime per-call assembly), ai-cost-guardrail-designer (prices the spend; this decides the CONTENT), and rag-security-architect (who may retrieve; this curates what retrieval feeds the window). Use when designing prompt/context assembly, deciding what an agent may see, or when context is stuffed ad hoc. DESIGNS the curated context; the poisoning attack review belongs to memory-context-poisoning-reviewer.

Design the schema and validation strategy for an LLM's structured output so downstream code never trusts an unvalidated response — define the output contract (fields, types, enums, ranges, formats), encode it in TYPES where possible so non-compliant output is unrepresentable, and walk every response up the ladder BEFORE use: parse → strict schema → policy/banned-content scan — failures logged as safety evidence and rejected, never silently repaired — plus bounded failure handling and semantic checks beyond shape (allowed sets, tenant-scoped ids, referential sanity). Shape-valid is not safe-to-act: validated output still goes to llm-output-safety-reviewer (sinks) and agent-tool-safety-guard (tool authz). Use when a model returns JSON/structured data an app parses, or to make an AI output contract enforceable. Do NOT use for injection/execution sinks (llm-output-safety-reviewer), tool permissions (agent-tool-safety-guard), factual accuracy (ai-misinformation-guard), or the routing layer (ai-router-architect).

The beginner-facing front door: take a non-developer from vague idea to shipped product with no jargon to learn. Detects the project's current stage (from docs/project-state.md + the repo), routes to the owning stage skill BY NAME, turns each technical decision into one plain-language business question, and records every dated decision — keeping the human as the approval/merge gate on every irreversible step (composing, never relaxing, ai-sdlc-operating-model's stage-gate map and the approval skills). Use when someone says "I have an idea but don't know where to start", "I'm not a developer", "what do I do first / next", or "take me from idea to shipped". Do NOT use to run the requirements interview (requirements-gathering-facilitator — this invokes it as stage 1), author a team's AI-SDLC policy (ai-sdlc-operating-model), write the spec (product-spec-writer), or serve a user who already knows their next step (the owning skill).

Design external API and event contracts for a multi-tenant SaaS — tenant context derived from credentials (never client-supplied tenant ids on data paths), resource/route conventions, versioning and deprecation policy with sunset windows, idempotency for mutations, per-tenant and per-plan rate limits, and webhook/event-feed contracts (versioned envelope schemas, tenant-scoped subscriptions, at-least-once delivery with retries, signing and replay protection). Produces API contract conventions, an event taxonomy with schemas, a webhook delivery policy, and a contract migration/rollback plan. Use when designing or overhauling a public API, adding webhooks or an event feed for integrations, when partners keep breaking on contract changes, or when API rate limiting needs a tenant/plan dimension. Do NOT use for the internal audit trail (audit-log-architect), internal service-to-service architecture (architecture-designer), or role/permission design (authorization-matrix-designer).

Advise on the architecture STYLE/paradigm for what someone is building — monolith, modular monolith, microservices, event-driven, serverless, service-oriented, or a hybrid — with honest, case-specific tradeoffs and a reasoned recommendation. Interview the need FIRST (domain, load, team size and operational maturity, constraints, scaling/change, consistency/latency) before advising; lay out only the genuinely relevant candidates for THIS situation (not a textbook dump); give case-specific pros/cons; make a clear recommendation WITH reasoning and state what would change it. Resists trend-chasing in both directions — often the honest answer is a boring modular monolith, and it says so. Use when choosing or reconsidering an architecture style/paradigm. Do NOT use to produce the concrete architecture/migration once the style is known (architecture-designer), decide cloud provider/posture (cloud-architecture-decider), design tenancy (saas-platform-architect), or model domain concepts (domain-modeler).

Design the authorization model for a multi-tenant SaaS as an explicit roles × permissions × resources matrix — platform roles vs tenant roles, object-level authorization rules for every tenant-owned resource, an enforcement-point map (UI, API, service, background job, integration), deny-by-default posture, impersonation/support-access rules, and a negative-test plan proving forbidden actions actually fail. Includes an additive migration and rollback path for role changes. Use when designing or overhauling roles and permissions, when authorization checks are scattered and inconsistent across the codebase, when adding a sensitive capability or a new role, or when support/admin access needs safe rules. Do NOT use for plan/feature gating — "does this PLAN include X" is plan-entitlement-architect; "can this ROLE do X" is this skill. Not for recording what happened (audit-log-architect) or for auditing existing RLS policies (Phase 4 security pack).

Design a single server-side-mediated write path — a command bus — for protected mutations in a multi-tenant SaaS: a command registry plus a per-command pipeline (validate payload → authenticate the actor from the token, never from client-supplied identity → authorize against policy → server-derive tenant/resource scope from trusted rows → idempotency → execute → emit audit + domain events → safe error envelope), plus the no-direct-client-writes invariant for protected actions. Produces the command catalog, the pipeline contract, and an enforcement-point map. Use when mutations are scattered across endpoints or client SDKs, when tenant scope is read from the request body, or when adding a sensitive write. Do NOT use for the external API/webhook contract (api-event-architect), the role/permission policy itself (authorization-matrix-designer), or the audit record schema (audit-log-architect) — this dispatches through them.

Design the CI gate that FAILS any PR touching "important" paths without a matching context-map/notes update, plus the update protocol that keeps the map honest: every update stamps date + commit SHA scanned, status moves only on cited evidence, and an unresolved risk note is never deleted — only replaced by proof. Deliverables: important-paths list, co-update rule with a declared (never silent) no-change-needed escape hatch, check logic + failure message, protocol doc. The WRITE-BACK half of the context loop: agent-startup-context-gate makes sessions READ verified context; this gate makes changes write it back under CI enforcement. Use when the context map drifts from the code, when "update the docs" is aspirational, or to enforce context freshness on PRs. Do NOT use for session-start context loading (agent-startup-context-gate), to design or edit the pipeline itself (ci-pipeline-architect — wiring hands off there), or for the chat-history sweep (chat-backlog-reconciliation).

Design the error model for an API or product surface — a finite, stable taxonomy of error categories with machine-readable codes, an error envelope (code, human message, field-level details, correlation id, retryable flag), an honest client-fault vs server-fault vs retryable split, actionable messages that say what to DO, ONE mapping boundary where exceptions become taxonomy errors, and a disclosure rule that keeps stack traces, internal identifiers, and PII out of what the caller sees. Owns the error MODEL and its wire/copy discipline; the endpoint contract carrying it is api-event-architect's, and rendering the error STATE in the UI is edge-state-ux-designer's. Use when designing or unifying error responses, error codes, or an error envelope, or when errors are inconsistent, leaky, or tell the user nothing they can act on. Do NOT use to design the API contract itself (api-event-architect) or the empty/loading/error UI (edge-state-ux-designer).

Review whether a system can scale OUT (add nodes) rather than only up — a can-it-scale-horizontally lens: statelessness / session and in-memory-state externalization, connection pooling and connection-count ceilings, sticky-session and in-process-singleton / local-cache / local-cron / local-filesystem smells, autoscaling + load-balancer + health-check config, and graceful shutdown/draining so scale-in does not drop work. Produces a scale-out readiness verdict with component/file findings ranked by blast radius and a remediation order. Use when reviewing readiness to run multiple instances or autoscale, when adding a second node breaks things, or when "it works on one box" must become many. Do NOT use to SET reliability targets (slo-reliability-architect), allocate a LATENCY budget (latency-budget-architect), or design the CACHE (caching-strategy-designer) — this reviews scale-out readiness and defers those.

Design a second mandatory data-scoping axis BELOW the tenant (location / site / region / org-unit / business-unit) for a multi-tenant SaaS — the per-user scope-grant model, the composite row-filter predicate on every scoped table (tenant_id AND scope), which roles are scope-restricted vs tenant-wide, server-derived propagation through app and edge layers, and the migration to add the axis to a live per-tenant schema. Presupposes the tenant boundary; this is a sub-tenant dimension inside ONE tenant, not a new tenant. Use when users in a tenant must see only a subset of its data by an org dimension (a store manager sees one store; a regional lead sees a region; admins see all). Do NOT use for tenant SEMANTICS or tenant hierarchy (tenant-modeler), tenant_id-axis storage strategy (multi-tenant-data-architect), or roles×permissions authz (authorization-matrix-designer). Reshapes live schema — DESIGNS the migration, does not run it.

Author the pre-work, evidence-cited guide a parallel agent lane needs BEFORE its first task: the lane's slice of the request lifecycle, the contracts it may rely on and must honor, a step-by-step recipe for its repeating unit of work, a per-unit checklist, and an explicit "what this lane must NOT do" boundary — every load-bearing claim cited to source files/PRs or labeled unverified, so the implementing agent starts from distilled verified knowledge instead of re-deriving it. One guide per lane; boundaries mutually exclusive; shared surfaces get a named owner. Planner-to-implementer transfer at work's BEGINNING. Use when splitting an effort across parallel agents/lanes, before a lane's first unit, or when parallel agents collide on shared files. Do NOT use for the end-of-work report/handoff (ai-closeout-reporter — work's END), the whole-lifecycle contract (ai-sdlc-operating-model), aligning tool instruction files (agent-instruction-consolidator), or recording lane approvals (scoped-approval-register).

Design the tenant-scoped data layer — choose and justify the scoping strategy per store (shared tables with tenant key, schema-per-tenant, database-per-tenant, or mixed), define the tenant-context propagation contract from request to query (server-derived, never client-supplied), map data ownership, handle shared/reference data, plan indexing and partitioning by tenant, and produce a tenant data migration plan with verification and rollback. Also outputs a data-layer isolation test matrix. Use when designing storage for a multi-tenant product, retrofitting tenant scoping onto existing tables, planning a tenant data migration/re-shard, or deciding where a new store (cache, search index, vector store) gets its tenant scoping. Do NOT use to define tenant semantics (tenant-modeler), to audit an existing system for leaks (tenant-isolation-reviewer), or to author/audit RLS policies — policy-level authoring and audit belong to the Phase 4 security pack.

Decide which workloads must leave the operational (transactional) store and how — classify queries by shape (OLTP point reads/writes vs OLAP scans/aggregations), find what is actually hurting the transactional path (long scans, lock pressure, dashboard fan-out, export jobs), choose the offload mechanism per workload (read replica, CDC into a warehouse/lake, materialized/pre-aggregated views, or a cache) against each consumer's stated freshness tolerance, and produce the split boundary with a staged cutover and a stop-doing list for the operational store. The DECISION skill: destination design is warehouse-lake-architect, CDC transport design is streaming-event-architect, and single-query tuning is query-plan-reader. Use when reports/dashboards/exports slow production, when analytics queries hit the primary, or when deciding replica vs warehouse vs cache for a read workload. Do NOT use to design the warehouse itself or to fix one slow query.

Machine-classify a change's touched files into impact classes that select validation DEPTH — docs-only fast path, fast tier, or full tier — with a classifier that FAILS CLOSED: unmatched, ambiguous, or error cases escalate to full, never down. Ships tier check bundles, an explicit docs-only definition PLUS a "never docs-only" list (workflows, scripts, schema/migrations, auth/RLS, lockfiles, agent-instruction files), forced-full lists for high-risk surfaces, and diffable rules; aggregation is max-over-files, no averaging. Routes validation COST where change-classification-gate routes APPROVAL — compose, don't merge. Use when picking fast vs full validation for a change, designing tiered validation, when docs-only changes waste full CI, or when risky files sneak through light checks. Do NOT use to set approval paths or scope lock (change-classification-gate), to run the selected tier (local-ci-mirror-preflight executes it), or to architect the full tier's shards (sharded-validation-with-resume).

Build the cost model for a multi-tenant SaaS — enumerate cost drivers (compute, storage, database, AI tokens, seats, third-party providers, support load), attribute costs to tenants and plans via tenant-tagged usage, compute unit economics (cost per tenant, per seat, per plan tier vs revenue), identify unbounded and variable-cost exposure (AI, egress, storage) and noisy-neighbor risk, and define cost guardrails (quotas, alerts, degradation ladders, per-tenant kill criteria) with a staged rollout and rollback. Use when asked what a tenant or plan actually costs, whether pricing covers cost, which tenants are unprofitable, before launching a feature with variable per-use cost, or when the cloud/AI bill grew and nobody knows which tenants drove it. Do NOT use for designing plan features and limit semantics (plan-entitlement-architect — this skill prices what that one gates), platform structure (saas-platform-architect), or general cloud architecture selection.

Design the end-to-end structure of a multi-tenant SaaS platform — control-plane/data-plane split, per-component tenancy deployment model (pooled, siloed, or mixed), identity architecture, platform capability inventory (onboarding, billing, audit, support, feature flags, analytics), and an incremental rollout/rollback plan — grounded in inspection of the current system first. Use when asked how to structure a SaaS product for multiple tenants, whether to pool or isolate tenants, what belongs in the control plane, or when converting a single-tenant app to multi-tenant. Do NOT use for defining tenant semantics alone (tenant-modeler), plan/entitlement design (plan-entitlement-architect), per-tenant cost modeling (saas-cost-architect), or structural questions with no tenancy dimension (architecture-designer).

Design full-tier validation as named functional shards with resume: a shard map assigning every test/check to exactly one shard, a persisted status file, resume that reruns ONLY unfinished shards after a timeout/infrastructure interruption (passes are kept; real FAILURES are never resumed-away), an "uncategorized" catch-shard that fails until new tests are assigned, and parallel shards funneling into ONE aggregate gate job as the sole required check — so docs-only conditional skips can't strand branch protection. Deliverables: shard map, status schema, runner modes, aggregate-gate spec, wiring handoff. Use when full validation times out or reruns from scratch after interruptions, when new tests escape unassigned, or when required checks break on skipped jobs. Do NOT use to choose the tier (risk-tiered-validation-selector), for the per-commit local mirror (local-ci-mirror-preflight invokes this runner), to design the pipeline (ci-pipeline-architect), or to diagnose flakes (flaky-test-detective).

Plan the safe retirement of a library skill — the lifecycle end. Establishes the trigger (superseded with a coverage diff, absorbed as an extension, evidence-backed disuse, defect), runs the reverse-link sweep (every neighbor description, trigger-eval, catalog/README row, or agent definition naming the skill gets a disposition), then stages the exit — mark (successor named), redirect for a grace window, remove (registration rows moved to a retired record, never silently deleted) — each stage with rollback (a squash-merged removal reverts as one ordinary commit). Plan only; executes nothing — removal is a human-approved operation. Use when asked to deprecate, retire, remove, or sunset a skill, prune the library on evidence, or after a reject/make-it-an-extension verdict. Do NOT use for doc lifecycle/retirement (docs-retention-index — now shipped), product-feature sunset messaging, usage-evidence gathering (skill-usage-instrumenter), or reviewing the removal PR (library-diff-reviewer).

Design the GOVERNED anti-approval-fatigue layer: a documented standing approval for the mechanical delivery loop (push, PR, monitor CI, fix red, pull) within NAMED scope; a phase-advance rule covering only already-named-and-approved phases; a prompt pattern restating the standing approval each session; an explicit opt-out phrase; and a reviewer-block path that suspends the loop. Merge-after-green is templated ONLY as an explicit opt-in deployment-profile choice — never the default — and standing approval NEVER covers protected-branch merge or arming auto-merge (human-only per agent-authorization-matrix). These elements are what separate this pattern from the ungoverned-auto-merge incident in that matrix's evals. Manual-only: it widens standing autonomy. Use when approval fatigue erodes real gates or every mechanical step re-asks permission. Do NOT use to record one grant (scoped-approval-register), define authority floors (agent-authorization-matrix), or stress-test approval UX (human-agent-trust-reviewer).

Design the INTERNAL event/streaming data backbone between services and stores — topic/stream taxonomy, partitioning and key choice (ordering stated as "per key, unordered across keys"), delivery semantics stated honestly (at-least-once with idempotent consumers; "exactly-once" claims interrogated), consumer groups, retry/dead-letter policy with replay procedure, retention vs compaction, backpressure/lag handling, event-schema compatibility rules, and CDC ingestion from operational stores. This is the data PIPELINE inside the system; the external contract surface — public webhooks, partner event feeds, signed envelopes, tenant-scoped subscriptions — is api-event-architect and stays there. Use when designing internal event flow, choosing stream vs queue, fixing ordering/duplicate bugs, or designing CDC. Do NOT use for the audit trail (audit-log-architect) or deciding which workloads leave the operational store (operational-vs-analytical-splitter).

Design cell-based (blast-radius) partitioning for a multi-tenant SaaS — a cell is a self-contained stack subset (compute + data + cache + queue) that serves a subset of tenants end to end, so a failure, bad deploy, or noisy tenant is contained to ONE cell instead of the whole fleet: cell definition, tenant→cell mapping and placement policy, a thin cell-router, cell-by-cell deployment/canary, cross-cell/global concerns, and cell migration/rebalancing. SCALE-STAGE — most SaaS never needs it; recommend cells ONLY when blast-radius reduction is the dominant lever, otherwise say so and stop. Use when a single shared stack's blast radius is the unacceptable risk or you need per-cell deployment isolation. Do NOT use for per-component pooled/siloed isolation of one store (saas-platform-architect), choosing the architecture STYLE (architecture-advisor, whose menu omits cells), or agent blast-radius (agent-containment-reviewer).

Design OLTP partitioning and sharding for WRITE/size scale in a multi-tenant SaaS — shard-key selection (tenant-as-shard-key and its hot-tenant limit), range/hash/list partitioning of large tables, resharding/rebalancing a hot tenant, and the cross-shard query/transaction costs you inherit — all gated behind the DON'T-SHARD-PREMATURELY rule: a single well-indexed primary plus read replicas serves a very large SaaS, so shard ONLY on evidence of a real write or size ceiling. Use when a primary has hit (or has a dated forecast to hit) a write/size ceiling that indexing and replicas cannot fix, when one hot tenant dominates a shared table, or when choosing a shard key/partitioning scheme. Do NOT use for per-store ISOLATION scoping (multi-tenant-data-architect), ANALYTICAL-estate partitioning (warehouse-lake-architect), or deciding WHAT leaves the OLTP store (operational-vs-analytical-splitter). Reshapes production data — DESIGNS the plan, does not run it.

Design guest/public share-link access for a multi-tenant SaaS — a CAPABILITY model where possession of an opaque, high-entropy, expiring, revocable token grants a fixed narrow scope, distinct from member RBAC: token design, ephemeral guest sessions (not memberships), optional password/OTP gating, per-link scope (which resource, which permission), enumeration/abuse defense, and audit. The link must expose exactly the shared resource and never become a hole into the rest of the tenant. Use when adding anyone-with-the-link view/comment/edit access for non-members (often unauthenticated), or designing the share token's entropy, expiry, revocation, and gating. Do NOT use for MEMBER roles×permissions or impersonation/support access (authorization-matrix-designer), or for API credentials / webhook signing / partner keys (api-event-architect). Produces a design/spec; do not invent crypto primitives — use vetted ones.

Design the internal ops/support/superadmin CONSOLE for a multi-tenant SaaS — the surface operators act THROUGH: cross-tenant read/write with MANDATORY audit on every action, impersonation/support-mode with hard boundaries + consent + audit, least-privilege admin tiers (view-ops / write-ops / superadmin), break-glass elevation (time-boxed, approved, auto-expiring, logged), and the operator control-plane (health, manual failover/retry, data-repair). Produces the console architecture, the admin-tier + impersonation enforcement design, the break-glass workflow, and the audit contract. Use when building an internal admin/support/superadmin tool, adding cross-tenant support access, or designing impersonation/break-glass safely. Do NOT use for the authorization POLICY itself (authorization-matrix-designer — this ENFORCES it), operator TELEMETRY (observability-operator), AI-agent authority (agent-authorization-matrix), or the incident PLAYBOOK (incident-response-runbook).

Design the async job/worker EXECUTION model for a multi-tenant SaaS — offload slow work off the request path: worker pools, scheduled/cron jobs, job idempotency + resumability/checkpointing, retry with backoff, a job dead-letter queue, visibility timeouts, and per-tenant fairness so one tenant's flood cannot starve others. Produces the job catalog, the execution/retry/DLQ contract, and a fairness + scaling plan. Use when moving slow work out of the request, adding scheduled jobs, or when jobs run twice, never finish, or one tenant's backlog starves everyone. This is EXECUTION (what RUNS the work); the message TRANSPORT (topics, partitions, delivery semantics, CDC) is streaming-event-architect. Do NOT use to MEASURE throughput/latency under load (performance-test-harness / load-test-planner) or to design the internal event backbone (streaming-event-architect).

Design file/object storage and upload flows for a multi-tenant SaaS — direct-to-storage vs proxied upload, short-lived signed URLs scoped to one object + verb + expiry, tenancy by bucket/path-prefix, size/type/CONTENT validation (magic-byte, not just extension), malware scanning, image/derivative processing off the request path, retention/lifecycle, CDN + cache-control, and storage-cost posture. Produces the upload-flow design, the storage-tenancy + signed-URL contract, the validation/scan pipeline, and the retention plan. Use when adding uploads, attachments, or media, when files must be tenant-isolated, or when uploads are slow, unsafe, or unbounded. Do NOT use for the personal-data lifecycle of file CONTENTS — consent, subject-access, deletion SLAs (pii-lifecycle-designer) — or for auditing existing storage RLS/bucket policies (rls-policy-auditor); this designs the storage + upload architecture and defers those.

Design the client OFFLINE data layer for a multi-tenant SaaS — write-while-offline queue, optimistic apply + rollback on server reject, conflict detection/resolution (last-write-wins / field-merge / CRDT / manual), local persistence (IndexedDB/SQLite), background sync when connectivity returns, and online↔offline reconciliation with integrity. Produces the sync-engine design, the conflict-resolution policy, the local-store + queue schema, and the reconciliation contract. Use when the app must work offline or on flaky networks, when queued offline edits conflict on reconnect, or when optimistic updates get lost or duplicated. Do NOT use for the offline/optimistic-rollback UX STATES themselves (edge-state-ux-designer — it renders the state; this is the engine behind it), the server/distributed CACHE (caching-strategy-designer), or live ONLINE server→client push (realtime-subscription-architect — the in-batch seam). This designs the sync engine; conflicts that silently lose data are refused.

Design real-time client delivery for a multi-tenant SaaS — WebSocket / SSE / database-change subscriptions / presence: the channel/topic model, authorize-at-subscribe-time (the per-tenant AND per-user leak boundary, re-checked as authority changes — never trusting a client-named channel), fan-out, scaling stateful connections across nodes, backpressure and slow-consumer handling, reconnect with replay/resume, and presence/typing state. Produces the channel taxonomy, the subscribe-time authorization contract, and a connection-scaling plan. Use when adding live updates, presence, or a subscription feed to clients, or when a live channel leaks another tenant's data. Do NOT use for the internal server-to-server event backbone (streaming-event-architect), the request/response API or outbound webhooks (api-event-architect), the offline write-sync engine (offline-first-sync-architect), or notification UX (notification-webhook-ux-designer).

Design search/discovery for a multi-tenant SaaS — in-database full-text (tsvector / trigram) vs a dedicated search engine chosen by scale and relevance need; the indexing pipeline and its freshness lag; relevance/ranking; the per-tenant search-isolation boundary (every query AND every index scoped so results never cross tenants — the search leak); and the faceting/pagination seam. Produces the engine decision, indexing + freshness plan, ranking model, and the tenant-isolation contract. Use when adding search, autocomplete, or discovery, when search is slow, stale, or irrelevant, or when search results must be tenant-isolated. Do NOT use for AI/semantic vector retrieval and its security (rag-security-architect), the base data-store tenancy model (multi-tenant-data-architect), or cursor/pagination mechanics (pagination-cursor-designer) — this designs keyword/faceted search and defers those.

Design ongoing black-box PRODUCTION monitoring — scheduled synthetic probes/journeys against the LIVE app and third-party deps from outside: the probe catalog (critical journeys + dependency health + heartbeat/canary), a HARD prod-safety contract (probes never mutate real data, never leak test fixtures, use ring-fenced synthetic accounts, self-clean), synthetic SLIs + alert-on-failure, and result capture/routing to a runbook. Produces the probe catalog, prod-safety contract, synthetic-SLI + alerting design, and runbook link. Use when monitoring whether production actually works from the user's perspective, adding uptime/journey/dependency probes, or catching outages before customers do. Do NOT use for pre-release load/perf MEASUREMENT (performance-test-harness / load-test-planner), CI E2E (playwright-e2e-engineer), SLO target-setting (slo-reliability-architect), or white-box instrumentation (observability-operator). This DESIGNS probes; it does not run them against prod.

Design the metering → pricing → rollup → reconciliation DATA PIPELINE for a multi-tenant SaaS — a billing-safe usage-event table (metadata only, no message/file CONTENT), time-bounded rate cards, cost entries carrying idempotency keys so replays and retries never double-bill, additive rollups (an analytical projection), budgets + breach alerts, spend forecast, and reconciliation of metered totals against provider invoices. Produces the event schema, rate-card model, idempotent cost-entry contract, rollup jobs, and reconciliation loop. Use when BUILDING the metering/billing pipeline, when usage numbers do not match the invoice, or when retries double-count. Do NOT use for the unit-economics COST MODEL — what a tenant costs, whether pricing is profitable (saas-cost-architect — closest neighbor, pinned hard), AI spend guardrails/kill-switch (ai-cost-guardrail-designer), or the operational-vs-analytical split (operational-vs-analytical-splitter).

Design cost and consumption guardrails for an LLM feature covering both spend and unbounded-consumption abuse (OWASP LLM10 — denial-of-service and denial-of-wallet) — per-request token caps (input and output), per-user/tenant/plan budgets and cost-aware (token-based, not request-count) rate limits, model selection by task, concurrency and queue limits, loop/recursion bounds for agents, input-size limits, a fail-closed spend kill switch and degraded-mode fallback, and cost/usage telemetry with alerts before the budget is gone. Composes saas-cost-architect for unit economics and observability-operator for the metering. Use when adding budgets/quotas/rate limits to an AI feature, or defending against token-drain, denial-of-wallet, or stolen-key LLMjacking. Do NOT use for whole-product cost modeling (saas-cost-architect), plan feature gating (plan-entitlement-architect), implementing the alerts (observability-operator), or model routing/fallback logic (ai-router-architect).