@raishin/vanguard-frontier-agentic 3.15.0 → 3.17.0

package/skills/cross-functional/agentic-system-architecture-review/references/delegation-and-handoff-review.md

@@ -0,0 +1,107 @@
+# Delegation and handoff review
+
+Use this reference after the pattern is chosen, to review how work and authority move between agents, tools and humans. The review is static: it reads the design, the contracts and the configuration that were supplied. It does not exercise any handoff.
+
+## Topology and delegation boundaries
+
+Draw the delegation graph from the supplied evidence before judging it. Nodes are agents, workers, tools and humans. Edges are delegations and handoffs. Mark on each node its trust domain, permission set and the highest data classification it touches, and mark where a human gate sits.
+
+For every edge, answer:
+
+- Who may delegate to whom, and is that written down or only implied by a prompt?
+- What travels with the delegation: the objective, the inputs, the permissions, the budget, the deadline, the prohibitions?
+- What comes back, in what shape, and who validates it before the next step uses it?
+- Who owns the outcome? Exactly one accountable owner per outcome; a delegating agent still owns what it delegates until it has verified the result.
+- Is the hop justified? Each hop adds latency, cost and a failure surface. Prefer shallow topologies and demand a reason for each added level (`inference`).
+
+Delegation is a privilege boundary. If a child needs authority its parent does not hold, that is an escalation to a human or to a different principal, not a delegation. Identity, token handling and confused-deputy paths belong to the security agent: see [identity and delegated authorization](../../agentic-security-review/references/identity-and-delegated-authorization.md) and hand the question over instead of answering it here.
+
+## Routing confidence and fallback
+
+A router that always picks something is guessing. Review these points:
+
+- Does the router emit a score, a confidence, or an explicit unclassified outcome? Unclassified must stop the flow and ask or escalate, never fall through to a default specialist that can act.
+- Where does the threshold come from: a labeled routing set that was measured, or a number someone chose? An unmeasured threshold is `inference`.
+- What happens on a tie, or when two specialists both match? Serialize, run read-only first, or ask; do not pick at random.
+- Is there loop detection (A routes to B routes to A) and a cap on re-routing?
+- Is the fallback side-effect free? A human queue or a read-only answer is a safe fallback; a default action-taking agent is not.
+- Is an action-taking specialist ever reachable by classification alone? Prefer a human or policy gate in front of any specialist whose tools mutate state.
+
+Repository pattern (`repo-evidence`): this repository's maestro routing gate in `tests/validate-maestro-routing.py` models an unclassified mode on zero score, and its live-guard agents are never auto-dispatched. Adopters can mirror the shape; the gate itself only checks this repository's fixtures.
+
+Plan-only scenarios to request from the owner: an ambiguous input, an input that names a specialist the user should not reach, an empty input, and an input that matches two specialists equally.
+
+## Handoff contract review
+
+A handoff is a contract between two parties that may fail independently. Review it as one. The board's own contract, [schemas/agentic-handoff.schema.json](../../../../schemas/agentic-handoff.schema.json), is a worked example. This reference does not restate its rules; the fields, the message types and the rule list live in the [handoff envelope reference](../../agentic-board-protocol/references/handoff-envelope.md).
+
+Ask of the design under review:
+
+- Is the handoff schema versioned, and is it validated at the receiving boundary rather than trusted because the sender is "one of ours"?
+- Does it carry the objective as a question, evidence references with labels, missing evidence flagged as blocking or not, the budget, the deadline, the permitted actions, the prohibitions, the data classification and the risk tier?
+- Is the channel closed? A side channel (shared scratchpad, free-form chat, a shared memory key) that bypasses the contract defeats it.
+- What does the receiver do with a malformed handoff: reject, or repair silently? Reject, and report.
+- Do handoffs carry secrets? They must not. Credentials belong to the runtime's identity layer, not the message.
+- Does each handoff carry a correlation identifier so the whole task can be reconstructed later?
+
+What a valid handoff does not prove: a schema checks shape only. Whether the sender is who it claims to be, whether it is authorized to send, and whether an approval really happened are runtime properties. The repository's rule module (`python3 tests/agentic-board-suite/agentic_board_rules.py <record-set.json>`) checks internal consistency of a record set offline; it authenticates nothing and enforces nothing at runtime. State this limit when the design relies on the contract for assurance.
+
+## Privilege attenuation down chains
+
+Authority should only narrow down a delegation chain, and sensitivity should only rise. Concretely, check that each child has no permitted action, budget, deadline, depth allowance or data reach larger than its parent's, and that the risk tier, data classification, materiality flags and prohibitions never shrink.
+
+Review questions:
+
+- Can a child be given a tool its parent lacks?
+- Does a child inherit the parent's credentials wholesale, or is it issued its own narrower, shorter-lived grant? (Credential handling goes to the security agent.)
+- Does a returned result carry authority back up the chain (an output that an upstream agent treats as an instruction)?
+- Is attenuation enforced by the runtime, or only written in a prompt or schema?
+
+The board encodes monotonic attenuation as checkable fields; see the [handoff envelope reference](../../agentic-board-protocol/references/handoff-envelope.md). Encoding is not enforcement. A schema rule that passes offline does not stop a runtime from granting more.
+
+## Loop and recursion bounds
+
+Every loop needs a bound that the runtime enforces, not one the model is asked to respect. Check for:
+
+- a maximum delegation depth and a maximum number of iterations per agent,
+- a round limit on critic, debate and challenge loops,
+- a task-level budget (tokens, tool calls, cost, wall-clock) shared down the tree,
+- repetition and no-progress detection (same tool, same arguments, same state),
+- what happens at the bound: stop and escalate, not "best effort."
+
+The board's computed stop conditions for depth, deadline, budget, missing evidence, routing loops and challenge rounds are defined in the [stop conditions reference](../../agentic-board-protocol/references/stop-conditions.md). They are fixture checks over envelope fields run by an offline gate. They are not runtime containment. Whether the design under review contains a loop at runtime is reviewed in [reliability and containment](reliability-and-containment.md).
+
+## Human-in-the-loop placement
+
+Place approvals where a wrong action is costly or irreversible, not on every step; constant prompts teach approvers to click through (`inference`). Usual placements: before an irreversible or external side effect, at any privilege escalation, at an unclassified or ambiguous routing result, and at a budget overrun.
+
+Review questions:
+
+- Can the system pause and resume? An approval that holds a connection open for hours is a durability defect. See [state, memory and durability](state-memory-and-durability.md).
+- Is the approver an authenticated individual, and is the approval bound to the exact action proposed (for example by a digest of the request) rather than to the agent's summary of it? The board binds a decision to a request by a sha256 digest of its canonical form; see the [decision record reference](../../agentic-board-protocol/references/decision-record.md). Authenticating the approver is a runtime task.
+- What happens on approval timeout or an unavailable approver? Fail closed: no action.
+- Can the agent re-ask with different wording until it gets a yes? Cap and log repeated requests.
+- Does the approval prompt show the real action and its arguments, or only a model-written description? A persuasive description can be an instance of Human-Agent Trust Exploitation (OWASP ASI09, per https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/); hand it to the security agent.
+- Does any agent approve its own or another agent's work? Agents never record approvals under the board contract.
+
+## A2A task lifecycle as a resumability boundary
+
+When agents communicate over the Agent2Agent protocol, the task lifecycle marks where work can pause and where it ends. From the specification at https://a2a-protocol.org/latest/specification/ (the latest released revision when this was verified on 2026-10-30; verify against the revision your implementation targets):
+
+- Interrupted states are INPUT_REQUIRED and AUTH_REQUIRED. The task is waiting on something outside the agent.
+- Terminal states are COMPLETED, FAILED, CANCELED and REJECTED.
+- The full state list, per the same specification (https://a2a-protocol.org/latest/specification/), is SUBMITTED, WORKING, COMPLETED, FAILED, CANCELED, INPUT_REQUIRED, REJECTED and AUTH_REQUIRED, spelled with a TASK_STATE_ prefix in the enumeration. The full enumeration was not re-verified here; check it against the revision you target.
+
+Design consequences to review:
+
+- An interrupted state is a durable wait, not a blocked thread. The design must persist what it needs to resume: the task identifier, the context, the pending question, and who must answer. It needs a timeout for a task never resumed. See [state, memory and durability](state-memory-and-durability.md).
+- A terminal state ends the task's lifecycle. Treat a retry as a new task unless the specification revision you target says otherwise.
+- State updates can repeat. Handle a duplicate transition idempotently.
+- Does the client treat REJECTED and FAILED differently? Verify what each means in the revision you target, and check that the follow-up behavior matches it.
+- AUTH_REQUIRED is not authorization. The specification states that agents "MUST NOT treat the TASK_STATE_AUTH_REQUIRED state transition, by itself, as authorization for any particular operation", and that a credential obtained in that state "MUST NOT be assumed to authorize subsequent messages on the Task unless that behavior is explicitly defined by the implementation, credential issuer, or extension". Review the lifecycle here; hand the authorization aspect, including security schemes and Agent Card signatures, to `agentic-security-review-agent`.
+
+## What to hand off
+
+- Authentication, delegated authorization, token handling, Agent Card trust: `agentic-security-review-agent`.
+- MCP tool-schema fidelity and protocol version for tools exposed over MCP: `typescript-mcp-tool-contract-agent`.
+- How to measure routing accuracy and task completion: `llm-ai-pipeline-test-review-agent`.

package/skills/cross-functional/agentic-system-architecture-review/references/pattern-selection.md

@@ -0,0 +1,81 @@
+# Pattern selection
+
+Use this reference to decide the lowest sufficient pattern for an agentic system and to read an orchestration design for its failure modes. It covers the technical rungs only. The business rungs eliminate, redesign and keep the existing process come before them, and the conventional-automation rung (rules engines, ERP-native matching, scripts, RPA) sits between the deterministic-workflow rung and the single-agent rung. The [value case reference](../../agentic-board-protocol/references/value-case.md) owns those business rungs and the value case. If the design under review never faced them, say so and route the question there instead of answering it here.
+
+Everything below is design judgment, labeled `inference`, unless a cell names a source. Framework facts come only from the delegate research snapshot further down this file, are labeled `documentation-based`, and carry the source lists stated there.
+
+## The technical rungs
+
+| Rung | Enter when | Evidence demanded | Move up only when |
+|---|---|---|---|
+| Deterministic workflow | Steps and branches are known at design time, inputs are structured or can be normalized, and each step can be tested alone. A step may call a model (classify, extract, draft) without making the flow agentic. | The step list or graph; the branch conditions; which steps call a model and why rules cannot replace that call; behavior on each step's failure; where state lives between steps. | The set of paths cannot be enumerated because the next step depends on what a tool or document returns, and a sample of real cases shows the workflow's branches miss some of them. |
+| Single agent with tools | The path depends on observed results, the tool set is small and bounded, one permission set and one trust domain cover every tool, and the conventional-automation alternative was considered and rejected with a reason (see the value case reference). | A tool list with the permission each tool needs; turn, tool-call and cost caps; an evaluation showing the agent reaches the outcome (design it with `llm-ai-pipeline-test-review-agent`); why a workflow with a model step was insufficient. | One of the four needs below is demonstrated and a single agent with a better prompt or more tools does not meet it. |
+| Multi-agent | At least one of the four needs below is demonstrated with evidence rather than asserted. | Evidence for each need claimed; the extra cost (model calls, latency, handoff surfaces, failure modes) accepted by the owner; the controls listed for the pattern in use. | Top rung. Re-justify it whenever the need changes. |
+
+### The four needs that can justify more than one agent
+
+| Need | Counts as evidence | Does not count |
+|---|---|---|
+| Separation of duties | A requirement or control that names the separation; the agents hold different permission sets and, ideally, different contexts, so the producer cannot verify or approve its own output. | Two prompts on the same tools with the same context. |
+| Parallelism | Independent subtasks (no shared writes) and a latency or throughput target that a sequential run misses, with measured or modeled timings. | "It might be faster." |
+| Context-window limits | Token measurements on real inputs showing the task does not fit one context, and an evaluation showing that summarizing or retrieving on demand loses decisive information. | An assumption with no measurement; retrieval or chunking never tried. |
+| Distinct tool permission sets | A tool-to-permission map showing the sets differ and cannot be merged without widening any principal's access. | One permission set split into prompt personas. |
+
+A claim of multi-agent need that supplies none of this evidence is `inference`. The verdict is simpler-pattern-sufficient, and the finding names the lower rung and what it would look like. Every extra agent adds model calls, a handoff surface and failure modes; the owner should accept that cost knowingly.
+
+## Orchestration patterns as vendor-neutral concepts
+
+A pattern is a shape of control flow, not a product. Most frameworks can express several of these, and a graph framework can express a deterministic workflow. Review the pattern first and the framework second.
+
+| Pattern | Use when | Failure modes | Control required |
+|---|---|---|---|
+| Supervisor or manager-worker | Subtasks differ in skill or permission and one coordinator must integrate the results. | Coordinator becomes a bottleneck and a single point of failure; worker output enters the coordinator's context as data that may carry instructions; unbounded re-delegation. | Depth and re-delegation cap; per-worker budget carved from the coordinator's; worker output treated as data; the coordinator can never widen a worker's permissions. |
+| Sequential pipeline | Stages are known, ordered and dependent. | An early mistake is laundered by later stages; no stage owns the end-to-end result. | Schema-validated stage boundaries; per-stage idempotency; stop on a failed validation instead of repairing silently. |
+| Concurrent fan-out and fan-in | Subtasks are independent and the merge rule is defined. | Fan-out explosion; partial failure; merge conflicts; cost spikes; inconsistent reads. | Fan-out cap; per-branch timeout; an explicit partial-result policy; a deterministic merge rule. |
+| Handoff or routing | A specialist should own the next step, or a router classifies the task. | Misrouting; routing loops; lost context; privilege carried across the handoff; guessing at low confidence. | A confidence threshold with an explicit unclassified outcome; hop cap; loop detection; minimal context transfer; attenuation of authority. |
+| Group chat or debate | Adversarial challenge adds value and its token cost is accepted. | Runaway conversation; agreement that comes from a shared model family; no deterministic termination; token blowup. | Round cap; a terminator condition outside the model; a transcript budget. Independence between same-model participants is procedural, not epistemic. |
+| Planner-executor-verifier | A plan can be validated before execution and verification costs less than the error it prevents. | Plan and execution drift; the verifier shares the executor's blind spots; a poisoned plan. | Executor limited to the plan's steps; a verifier with its own context and permissions; a digest binding approval to the exact plan. |
+| Generator-critic loop | Output quality improves under critique and acceptance criteria are objective. | Oscillation; endless refinement; the generator gaming the critic. | Iteration cap; objective acceptance criteria; stop when an iteration produces no improvement. |
+| Event-driven | Work is asynchronous, long-lived, or integrates with existing queues and systems. | Duplicate and out-of-order delivery; poison messages; event loops and storms; hidden coupling. | Idempotent consumers; a dead-letter path; versioned event schemas; a loop breaker; a stated ordering assumption. See [webhook delivery: dedup and ordering](../../revenue-critical-journey-integrity-review/references/webhook-delivery-dedup-ordering.md) for the consumer-side checks. |
+| Graph or stateful workflow | Control flow branches or cycles, needs pause and resume, or needs human approval mid-run. | State schema drift between versions; checkpoint bloat; cycles that never terminate; conflicting writes to shared state. | State schema versioning; checkpoint retention; a cycle bound; defined merge rules for shared state. |
+
+## Framework primitives (research snapshot)
+
+Versions drift. Verify against Context7 or the official docs for the installed version before asserting any cell about the system under review. No version numbers are recorded here on purpose. The cells come from a delegate research pass on 2026-10-30 and are labeled `documentation-based`. Not every cell maps to a page listed under the table, and none was re-verified against an installed version. Treat the table as a lead for the review, not as a finding.
+
+| Framework | Orchestration primitive | Human-approval primitive | Persistence and replay | Caveat |
+|---|---|---|---|---|
+| LangGraph | StateGraph, subgraphs, Functional API | interrupt() resumed with Command(resume=); needs a checkpointer | Checkpointers keyed by thread_id | The langgraph-supervisor library is archived; its README, as researched, recommends building the supervisor from tools. Verify which checkpointer backend is configured and whether it survives a restart. |
+| OpenAI Agents SDK | Handoffs, Agent.as_tool(), guardrails | needs_approval produces interruptions; RunState approve or reject | Sessions retrieve and store conversation history; the docs list Dapr, Temporal, Restate and DBOS integrations separately, for durable orchestration of long waits, retries and process restarts | Pre-stable release line; the research noted breaking changes between minor releases, so pin and re-verify. |
+| Microsoft Agent Framework | Sequential, concurrent, handoff, group chat and magentic orchestrations | RequestPort and request_info; tool approval; plan review in magentic | Superstep checkpoints; a Durable Task extension exists but its status was not verified | The research characterized the durability options as Azure-oriented; verify the extension's status and scope. |
+| Google ADK | Sequential, Parallel and Loop agents plus LLM delegation; the newer major line adds graph and dynamic workflows (whether they supersede the first three is not stated on adk.dev/workflows; unverified) | Graph RequestInput; Tool Confirmation (marked Experimental) | SessionService; the in-memory implementation is lost on restart | A2A support was marked Experimental. Check which workflow model the installed version offers. |
+| CrewAI | Crews (sequential or hierarchical) and Flows | The @human_feedback decorator | @persist and checkpointing | The default A2A protocol revision was noted as a pre-stable one; compare it with the A2A release you need to interoperate with. |
+| LlamaIndex Workflows | Event-driven steps (@step) | InputRequiredEvent and HumanResponseEvent | Ephemeral by default; Context.to_dict for serialization; a DBOS-backed runtime for durability | A2A support was not established by the research. |
+| Bedrock AgentCore | None. It hosts any framework and is not an orchestrator | Gateway elicitation and Policy | Memory service and Runtime sessions; no workflow replay | Review the hosted framework's orchestration and durability separately. Use `aws-agentcore-agent` for AgentCore specifics. |
+| Temporal | Workflows, activities and timers | Signals and updates with wait_condition | Event-history replay with deterministic workflow code, as reported by the research pass; the page listed below does not show this, so verify against the Temporal documentation for the installed version | The research pass noted official integrations for the OpenAI Agents SDK, LangGraph (public preview) and ADK (pre-release). The listed page is an index and gives no statuses, so verify each integration's status on its own page before relying on it. |
+
+Pages the research pass consulted (page-to-claim mapping within each list was not recorded, and a listed page may not support every cell):
+
+- LangGraph: https://docs.langchain.com/oss/python/langgraph/persistence and https://docs.langchain.com/oss/python/langgraph/interrupts
+- OpenAI Agents SDK: https://openai.github.io/openai-agents-python/multi_agent/, https://openai.github.io/openai-agents-python/handoffs/, https://openai.github.io/openai-agents-python/human_in_the_loop/ and https://openai.github.io/openai-agents-python/running_agents/
+- Microsoft Agent Framework: https://learn.microsoft.com/agent-framework/workflows/orchestrations/, https://learn.microsoft.com/agent-framework/workflows/checkpoints/ and https://learn.microsoft.com/agent-framework/workflows/human-in-the-loop/
+- Google ADK: https://adk.dev/workflows/, https://adk.dev/sessions/state and https://adk.dev/a2a
+- CrewAI: https://docs.crewai.com/en/concepts/flows
+- LlamaIndex Workflows: https://developers.llamaindex.ai/python/llamaagents/workflows/durable_workflows/
+- Bedrock AgentCore: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/release-notes.html
+- Temporal: https://docs.temporal.io/develop/python/integrations (an integrations index; it does not by itself support the replay, determinism or integration-status cells above)
+
+Reading the table:
+
+- Durable execution is not native in most agent SDKs. The generalization is `inference`, drawn from the OpenAI Agents SDK row (the docs present sessions and the durable-orchestration integrations as separate things) and the ADK row (in-memory sessions are lost on restart). A multi-agent framework is not a durable workflow, so the review must ask where durability comes from. See [state, memory and durability](state-memory-and-durability.md).
+- AgentCore hosts frameworks rather than orchestrating them. A design that says "AgentCore orchestrates our agents" has an unreviewed orchestration layer.
+- An archived library, an experimental feature, or a preview integration is a finding when the design depends on it for a control (approval, persistence, A2A). Condition the verdict on a verified replacement or an accepted risk.
+
+## Recording the result
+
+Write down, for the verdict:
+
+- the lowest sufficient rung and the evidence that supports stopping there,
+- each higher rung rejected, with the missing evidence named,
+- for a multi-agent verdict, the demonstrated need from the four above and the controls required for each pattern used,
+- the framework facts relied on, each labeled `context7-grounded` or `documentation-based`, or marked "verify against the official docs for the installed version".

package/skills/cross-functional/agentic-system-architecture-review/references/reliability-and-containment.md

@@ -0,0 +1,86 @@
+# Reliability and cascading-failure containment
+
+Use this reference to review whether a failure in one agent, tool, model or tenant stays where it started. Cascading-failure containment is owned here: the board's one-owner table gives it to the architecture review, while attack-driven failures belong to the security agent and unit prices belong to `finops-ai-economist-agent`.
+
+Containment is a runtime property. This reference reviews whether the design has it and whether the controls are enforced outside the model. This repository enforces none of it at runtime: its stop conditions are computed over handoff-envelope fields by an offline gate and are fixture checks, not containment (see the [stop conditions reference](../../agentic-board-protocol/references/stop-conditions.md)).
+
+## What a cascade looks like
+
+OWASP lists Cascading Failures as ASI08 in its Top 10 for Agentic Applications (per https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/). In design terms the mechanisms to look for are:
+
+- retry amplification, where layered retries multiply load on a dependency that is already struggling,
+- fan-out explosion, where one request spawns many subtasks that each spawn more,
+- agent loops that keep spending tokens and tool calls without progress,
+- a slow or failing dependency that grows queues until other work starves,
+- one tenant's workload consuming a shared model quota or worker pool,
+- errors that one agent returns being consumed as facts by the next agent and compounded.
+
+If a cascade starts from an attacker's input rather than a fault, hand it to `agentic-security-review-agent`.
+
+## Controls to look for
+
+| Control | What to look for | Failure if absent | Evidence to request |
+|---|---|---|---|
+| Budgets per task | Tokens, tool calls, cost, wall-clock and depth, enforced by the runtime and carved down the delegation tree (a child's budget comes out of its parent's). Exhaustion stops the task and escalates; it does not degrade to "best effort". | A single runaway task spends the quota for everyone. | Runtime configuration, not a prompt instruction; a trace of a task hitting its limit. |
+| Fan-out caps | Maximum parallel branches and maximum total subtasks per task, a per-branch timeout, and a stated partial-result policy. | Exponential spawning; partial results presented as complete. | The cap values and where they are enforced. |
+| Circuit breakers on tool and model calls | Per-dependency breakers that open on error rate or latency, probe before closing, and have a defined fallback while open. | Retries pile onto a failing dependency; the failure spreads upstream. | Breaker settings per dependency; the fallback each breaker triggers. |
+| Bulkheads | Separate pools, queues and quotas between tenants and between workflows, with per-tenant rate and budget limits. | One tenant or one workflow starves the rest. | Quota and queue topology; the per-tenant limit values. |
+| Loop and no-progress detection | Detection of repeated tool calls with the same arguments, repeated state, and iterations without improvement, with a hard cap. | Silent loops that look like long-running work. | The detector, its thresholds, and the action it takes. |
+| Backpressure and load shedding | Bounded queues; early rejection with a clear status instead of unbounded buffering. | Latency grows without bound, then everything times out at once. | Queue bounds; the behavior at the bound. |
+| Degraded modes and safe fallbacks | A defined behavior per dependency: serve cached or read-only results, route to a human queue, or return a partial result with an explicit flag. Fail closed for authorization and approval dependencies: when the approval service is down, nothing executes. Fail open only for non-safety features and only by explicit decision. | Ad hoc behavior during an outage, often fail-open. | The fallback table, and the owner's decision for each fail-open choice. |
+| Kill switch and disengage path | The ability to stop one task, one tenant, one agent type, or the whole system without a deployment; named roles who may pull it; defined effect on in-flight tasks (pause, cancel, or compensate); tested. | A misbehaving system cannot be stopped quickly. | Runbook, the access list, and the date of the last drill. |
+
+Treat a fallback model as a different dependency: it may have different data handling and different guardrails. A breaker that switches models must not change authorization or data residency (`inference`).
+
+### Kill switch and the NIST AI RMF
+
+NIST AI RMF MANAGE 2.4 addresses mechanisms to supersede, disengage, or deactivate AI systems (per https://airc.nist.gov/airmf-resources/airmf/5-sec-core/; read the subcategory text there for its exact wording). Use it as a candidate mapping aid when an owner asks which framework language a kill-switch finding relates to. It is not a claim that any design satisfies the subcategory; an accountable owner confirms any mapping. The same page carries the banner "The AI RMF 1.0 is being updated. A revised version is in progress." so re-check the subcategory text before citing it.
+
+## SLOs for agent tasks
+
+An agent system that has no service objectives cannot tell a regression from a bad day. Ask for:
+
+- Task success rate, with success defined against a quality bar that an evaluation measures. Design the evaluation with `llm-ai-pipeline-test-review-agent`.
+- Time to completion as a distribution, including the tail where retries and loops show up.
+- Human intervention rate and escalation rate. A rising intervention rate is a cost the value case must carry.
+- Cost per successful task, reported as a distribution and not as a mean.
+- An error-budget policy: what changes when an objective is burned. A reasonable default is to freeze changes that expand autonomy until the budget recovers (`inference`).
+
+On cost, report cost per successful task as a distribution rather than a mean, per https://www.finops.org/wg/finops-for-ai-overview/; the definition and the formula live in the [value case reference](../../agentic-board-protocol/references/value-case.md), and unit prices for models and tokens are not owned here.
+
+This repository holds no baseline for any of these objectives. An adopter measures its own.
+
+## Observability hooks
+
+Caveat first. Per https://github.com/open-telemetry/semantic-conventions-genai, the OpenTelemetry GenAI semantic conventions are maintained in that repository and are at Development status, which means no stability guarantee. Never present them as a stable contract. Pin the convention version in the telemetry configuration and expect renames (`inference`).
+
+Span names recorded in the agent-spans page (per https://raw.githubusercontent.com/open-telemetry/semantic-conventions-genai/main/docs/gen-ai/gen-ai-agent-spans.md):
+
+- create_agent {gen_ai.agent.name}
+- invoke_agent {gen_ai.agent.name}
+- invoke_workflow, used as the operation name
+
+Per https://github.com/open-telemetry/semantic-conventions-genai, an execute_tool {gen_ai.tool.name} span and these attributes are also listed: gen_ai.operation.name, gen_ai.agent.id, gen_ai.agent.name, gen_ai.agent.version, gen_ai.conversation.id, gen_ai.usage.input_tokens, gen_ai.usage.output_tokens, gen_ai.tool.name, gen_ai.tool.call.id, gen_ai.provider.name and gen_ai.request.model. That list was not independently re-verified; check the repository for the version in use.
+
+What to review in the design:
+
+- Can one task be reconstructed end to end: delegation hops, tool calls, retries, approvals, and breaker state changes? A single trace or correlation identifier must follow the task across handoffs. The board's handoff contract carries correlation and task identifiers for the same reason; see the [handoff envelope reference](../../agentic-board-protocol/references/handoff-envelope.md).
+- Are budgets spent and limits hit visible as events or metrics?
+- Do spans and attributes carry prompts, tool arguments or results? They may hold sensitive data. Apply the data classification and redaction before export.
+- Is observability mistaken for audit? Traces are commonly sampled and mutable. Audit evidence needs an append-only store owned by the deploying runtime; this repository stores no audit records.
+
+## What to hand off
+
+- Attack-driven cascades, poisoned inputs, and abuse of the kill switch: `agentic-security-review-agent`.
+- Evaluation design for success-rate objectives: `llm-ai-pipeline-test-review-agent`.
+- Model and token unit prices: `finops-ai-economist-agent`.
+- Value-case treatment of oversight and run cost: the protocol value case.
+
+## Plan-only containment probes to request
+
+This skill never runs them. Ask the owner for the results, or for a plan to obtain them:
+
+- a tabletop drill of the kill switch against a task that holds a pending side effect,
+- a scenario in which one dependency becomes slow, to see which breakers open and what fallback each triggers,
+- a runaway-loop scenario that must hit the budget cap and stop,
+- a noisy-tenant scenario, to see whether other tenants' latency and quota are protected.

package/skills/cross-functional/agentic-system-architecture-review/references/state-memory-and-durability.md

@@ -0,0 +1,102 @@
+# State, memory and durability
+
+Use this reference to review what an agentic system remembers, what survives a failure, and what happens when a step runs twice. Pattern selection decides who does what; this decides what persists and what is safe to repeat.
+
+Memory poisoning (an attacker writing into long-term memory or context) is a security threat owned by the security agent. This reference covers memory as a state-lifecycle concern only; for the threat, see [tools, memory and data reach](../../agentic-security-review/references/tools-memory-and-data-reach.md).
+
+## State scope
+
+Every piece of state belongs to one scope. Ask for an inventory that names, for each scope, the owner, the schema and its version, the store, the retention, the deletion path, the isolation key, and who may read and write.
+
+| Scope | Typically holds | Lifetime | Isolation key | Review questions |
+|---|---|---|---|---|
+| Per task | Working state, intermediate results, pending approvals, tool-call results | Until the task ends plus an audit retention period | Task identifier | Is it checkpointed? Who can read it after the task ends? Does it copy restricted data into a lower-classified store? |
+| Per conversation or session | Message history, summaries | The session | Session identifier within a tenant | What bounds its growth? Is a summary treated as a trusted source later? |
+| Per user or tenant | Long-term memory, preferences, cached retrievals | Until deleted or expired | Tenant and user keys enforced by the store | Is isolation enforced by the store or only by a prompt? Does it expire? |
+| Per system | Configuration, prompts, tool registries, caches | Until redeployed | Environment | Is a change versioned and attributable? |
+
+Isolation that exists only in a prompt ("only use this tenant's data") is not isolation (`inference`). Request evidence that the store enforces the partition key on reads and writes, and a plan-only cross-tenant retrieval test.
+
+## Memory isolation, retention and deletion
+
+- Retention. Every memory class needs an explicit expiry or a documented reason to have none. Long-term memory with no expiry and no review is a finding.
+- Deletion. A deletion request must reach every copy: the memory store, checkpoints, replicas, caches, vector indexes, derived summaries, and any recorded execution history that captured the data. Deleting the memory store while checkpoints still hold the same content is a failed deletion.
+- Replay history. Where a system replays from recorded history, payloads in that history fall inside the deletion scope. Ask how the engine supports redaction or expiry of recorded payloads, and verify against its docs for the installed version. Prefer recording references to data over recording the data itself (`inference`).
+- Classification travels with state. Restricted data must not be checkpointed or summarized into a store with a lower classification.
+- Backups. State the backup policy for deleted data; "deleted" and "removed from backups after N days" are different claims and should be stated separately.
+
+## Checkpointing
+
+A checkpoint is what lets a task resume after a pause or a failure. Review:
+
+- What is captured: state after each side-effecting step, the pending approval, the tool results already obtained, and the position in the flow.
+- Granularity. Checkpointing only at the end of a task defeats the purpose; checkpointing every token is wasteful. Ask what the design loses on a crash at its worst moment.
+- Resume semantics. Resuming from the last checkpoint re-executes whatever came after it. Any side effect in that window must be safe to repeat; see idempotency below.
+- Schema versioning. What happens to in-flight tasks when the state schema or the flow definition changes on deploy?
+- Retention and size. Checkpoints grow and may hold sensitive data; they need the same retention and deletion treatment as other state.
+
+Framework checkpoint primitives (for example LangGraph checkpointers keyed by thread identifier, and Microsoft Agent Framework superstep checkpoints, per the sources in [pattern selection](pattern-selection.md)) are documentation-based leads. Verify the backend and its restart behavior for the installed version.
+
+## Finding: agent session storage is not durable execution
+
+State this finding whenever a design calls session or history storage "durable":
+
+- Per https://openai.github.io/openai-agents-python/running_agents/, OpenAI Agents SDK sessions automatically retrieve conversation history before each run and store new messages after each run. The same page lists separate integrations (Dapr, Temporal, Restate and DBOS) as "durable orchestration when runs may span long waits, retries, or process restarts". The page does not say whether sessions are or are not durable execution.
+- Per https://adk.dev/sessions/state, the in-memory session service is lost when the process restarts.
+- Both facts are `documentation-based` and were not verified against an installed version. The conclusion drawn from them is `inference`: a store of conversation history does not by itself record which side effects a run already performed, or resume a half-finished run at the step that failed. The generalization that durable execution is not native in most agent SDKs is also `inference`. Verify the installed version.
+
+The review test: kill the process mid-task. Where does the task resume, what does it repeat, what is lost, and who finds out? A design that cannot answer has no durable execution regardless of how much history it stores.
+
+Durable execution is needed when a task waits for a human or an external event, runs longer than a request, has side effects that must take effect once, or carries a completion commitment. It is not needed for a short single-request flow whose steps are read-only or idempotent; there, retrying the whole request is a valid design. Severity guidance: block when a multi-step process with side effects, long waits or approvals has no durable mechanism and a failure scenario is reachable; otherwise make it a condition.
+
+## Idempotency keys for side-effecting tool calls
+
+A tool call that changes state needs a way to be repeated safely, because retries, resumes and replays will repeat it.
+
+- Generate the key before the call and store it with the result. A fresh random key per attempt defeats the purpose: derive it from the stable identity of the business operation and the step.
+- Bind the key to the recorded decision, not to regenerated text. A model may produce different arguments on a second attempt; the key and the arguments must be recorded together and reused.
+- The receiving system must deduplicate on the key and return the original result on a repeat. If the tool does not support keys, wrap it with an outbox or a check-then-act under a uniqueness constraint, or do not retry it automatically.
+- Define the key's scope and lifetime. A key that expires before the longest retry or resume window protects nothing.
+- The repository's own live-guard contract requires an idempotency key generated before the write and recorded in the audit log (docs/execution-tiers.md, `repo-evidence`). That contract governs this repository's gated guards, not your system, but it is a usable reference shape.
+
+For money-moving and account-creating seams see [idempotency and safe retries](../../revenue-critical-journey-integrity-review/references/idempotency-and-safe-retries.md).
+
+## Timeouts, retries and backoff
+
+- Every external call, including model calls, has a timeout.
+- Retries are bounded: a cap on attempts, exponential backoff with jitter, and a cap on delay. Retry only errors classified as transient. A side-effecting call without an idempotency key is not retried automatically.
+- Retries share a task-level budget. Layered retries (client, gateway, agent, tool) multiply; count them across layers and charge them to the task.
+- Separate transient failures (rate limits, timeouts) from content failures. A model output that fails schema validation gets a bounded number of repair attempts and then stops and escalates; it does not loop.
+- Retrying a model call changes the output. If the first output was already acted on, a retry is a different decision, not a repeat.
+
+## Compensation (saga) design
+
+When a task spans systems with no shared transaction, plan the undo as part of the design.
+
+- Each step has a compensating action, or is explicitly marked non-compensable.
+- Identify the pivot step, the point after which the task can only move forward, and put the human approval and the highest scrutiny immediately before it.
+- Compensations are idempotent and retried like any other step.
+- A failed compensation has a defined owner and path, normally a human queue, not silence.
+- Partial completion is visible to users and operators; a half-done task must not look finished.
+- A compensating action is itself a mutation and needs the same authorization as the original. Under the board contract, agents recommend compensations; they never execute them.
+
+## Replay safety
+
+Where a runtime recovers by replaying recorded history, the replayed code must reach the same decisions every time.
+
+- Durable-workflow engines such as Temporal are reported to recover by replaying recorded event history, which requires deterministic workflow code. This reference did not corroborate that against a primary page, so treat it as a lead and verify against the Temporal documentation for the installed version.
+- Nondeterministic work (model calls, tool calls, clock reads, random numbers) must run as recorded activity or step results, so a replay reuses the recorded result instead of calling again.
+- Review: is the model call inside the replayed workflow function, or in a recorded step? A model call in the replayed path will return something different on replay.
+- Are the prompt version, model identifier and tool schema version recorded beside each result, so an investigator can see which version produced it?
+- What happens to in-flight tasks on a deploy that changes the flow? Ask for the versioning strategy.
+- A low sampling temperature is not determinism (`inference`). Do not accept it as a substitute for recorded results.
+
+## Plan-only probes to request
+
+This skill never runs them. Ask the owner for the results, or for a plan to obtain them:
+
+- kill the process between a side effect and its checkpoint, then resume,
+- deliver the same input or event twice,
+- let an approval expire and confirm nothing executes,
+- delete one user's data and check checkpoints, indexes and summaries,
+- deploy a state schema change while a task is paused.

package/skills/cross-functional/agentic-system-architecture-review/references/workflow-and-output.md

@@ -0,0 +1,135 @@
+# Workflow and output contract
+
+Use this reference for an end-to-end architecture review of an agentic system. It fixes the order of the steps and the shape of the result so two reviews of the same design converge on the same findings. The review is static: it reads what was supplied and executes nothing.
+
+## Workflow
+
+1. **Classify the scope.**
+   - Identify what was supplied (design document, code, configuration, trace export) and whether the system is single-vendor. A single-vendor system goes to that vendor's agent; a system that composes vendors or a custom framework stays here for the seams. The routing list is in the skill.
+   - Name the decision under review and its canonical risk tier, R0 to R5, using the [risk tier crosswalk](../../agentic-board-protocol/references/risk-tier-crosswalk.md). The envelope's tier is the tier of the decision under review; the board's own work is static review. Never invent or redefine an R-label.
+   - Set materiality flags from the schema's list: financial, regulatory, security-critical, external-communication, personal-data, irreversible. A flag forces full-depth review and escalation to a principal. It never changes the tier.
+   - The decision class is architecture.
+2. **Gather evidence.**
+   - List every evidence reference with its label: `live-evidence`, `repo-evidence`, `user-provided-sanitized-evidence`, `context7-grounded`, `documentation-based`, or `inference`.
+   - List missing evidence and mark each item blocking or not. Blocking missing evidence means stop and escalate to a principal; do not guess. See the [stop conditions reference](../../agentic-board-protocol/references/stop-conditions.md).
+   - Ground framework API claims in Context7 for the installed version when the harness provides it. Otherwise write "verify against the official docs for the installed version".
+   - Redact and flag any credential-shaped string that appears in the material. Do not echo it.
+3. **Find the lowest sufficient pattern.** Walk the rungs in [pattern selection](pattern-selection.md) from the bottom. Record each rejected rung with the missing evidence that rejects it. Before accepting the single-agent rung, check that the conventional-automation alternative was considered (see the [value case reference](../../agentic-board-protocol/references/value-case.md)); if it was not, say so and route that question to the protocol instead of answering it here.
+4. **Review delegation and handoff.** Use [delegation and handoff review](delegation-and-handoff-review.md): topology, routing fallback, handoff contract, attenuation, loop bounds, human placement, and the A2A lifecycle if A2A is in use.
+5. **Review state and durability.** Use [state, memory and durability](state-memory-and-durability.md): scope, isolation and deletion, checkpointing, idempotency, retries, compensation, replay.
+6. **Review reliability and containment.** Use [reliability and containment](reliability-and-containment.md): budgets, caps, breakers, bulkheads, fallbacks, kill switch, SLOs, observability.
+7. **Reach the verdict.** Pick exactly one outcome.
+   - pass: the pattern is the lowest sufficient one and no finding stands.
+   - pass-with-conditions: the pattern is acceptable and each condition is specific and verifiable.
+   - block: a finding with a reachable failure scenario in the design as documented has no accepted fix.
+   - simpler-pattern-sufficient: a lower rung meets the stated need and the proposed topology lacks a demonstrated need. Return this even when the proposed topology also has blocking findings, and list them so they are not reintroduced.
+   Block only on a failure scenario you can describe from the evidence. A general unease is not a block.
+8. **Hand the verdict to the designated challenger.** For an architecture decision the designated challenger is `agentic-security-review-agent`. Send it a delegate envelope whose objective is a review question ("Assess whether ..."), not an instruction, with attenuated actions, a budget, a deadline and a do-not-do list, per the [handoff envelope reference](../../agentic-board-protocol/references/handoff-envelope.md). At R0 and R1 without materiality flags the challenge is optional under the protocol, but still name the designated challenger in the result. Its challenge references your verdict; the challenge round limit is in the stop conditions reference. Record the challenge outcome as it comes; never delete an unresolved one. Independence here is procedural, not epistemic: a separate contract and context, possibly the same underlying model family.
+9. **Raise the decision request.** For R2 and above, with any materiality flag, or for an automation-investment decision, the protocol requires an attached challenge and at least one materially different alternative, and a decision request addressed to a human principal with dissent preserved. For R0 and R1 without materiality flags the challenge is optional and a return envelope with the verdict is enough. See the [decision record reference](../../agentic-board-protocol/references/decision-record.md). Agents never decide and never record an approval.
+
+## Output template
+
+```markdown
+# Architecture review: <system name>
+
+Verdict: <pass | pass-with-conditions | block | simpler-pattern-sufficient> - one sentence.
+Status: proposal. Not approved. Designated challenger: <agent id>. Decision owner: a human principal.
+
+## Scope
+- Supplied: <artifacts and their evidence labels>
+- Decision class: architecture. Canonical risk tier of the decision under review: <R0-R5>.
+- Materiality flags: <list or none>. Single-vendor or cross-vendor: <which>.
+
+## Lowest sufficient pattern
+<rung> - why it is sufficient, and the evidence.
+
+### Rungs considered and rejected
+| Rung | Rejected because | Missing evidence |
+|---|---|---|
+
+## Findings
+| ID | Severity | Area | Failure scenario | Evidence label | Fix direction | Verification step |
+|---|---|---|---|---|---|---|
+
+Severity is blocking (reachable failure scenario, no accepted fix), condition (acceptable only with a named, verifiable change), or advisory.
+
+## Evidence and gaps
+- Evidence used, each with its label.
+- Missing evidence, each marked blocking or not.
+- Not reviewed here or runtime-only: <list>
+
+## Handoffs
+- <agent id>: <what it receives and why>
+
+## Decision request
+<For R2 and above, with any flag, or for automation investment: alternatives, challenges, dissent, recommended outcome. Otherwise state that the challenge is optional per the protocol.>
+```
+
+Rules for the result:
+
+- Every finding carries a failure scenario that says how the design reaches a wrong outcome. A finding without one is an opinion; drop it or mark it advisory.
+- Never present a framework fact without its label or a "verify against the official docs for the installed version" note.
+- Never write that a design satisfies a framework or is certified or compliant. A mapping is a candidate that an accountable owner confirms.
+- Never include credentials, tokens, tenant identifiers, names or email addresses.
+
+## Example verdict (synthetic)
+
+This example is invented for illustration. No real system, team or data is described.
+
+Scenario: a fictional team proposes a five-agent group-chat design (intake, classifier, researcher, resolver, reviewer) to triage invoice disputes for a non-production pilot. A sanitized design document was supplied.
+
+```markdown
+# Architecture review: invoice dispute triage (synthetic)
+
+Verdict: simpler-pattern-sufficient - a deterministic workflow with two model steps and a human approval meets the stated need.
+Status: proposal. Not approved. Designated challenger: agentic-security-review-agent. Decision owner: a human principal.
+
+## Scope
+- Supplied: design document (user-provided-sanitized-evidence).
+- Decision class: architecture. Canonical risk tier of the decision under review: R2 (pilot scoped to a non-production environment).
+- Materiality flags: financial. The flag forces a designated challenge and a principal decision; it does not change the tier.
+
+## Lowest sufficient pattern
+Deterministic workflow: classify the dispute into the fixed taxonomy (one model call), fetch facts with fixed read-only tools, draft a reply (one model call), require a human approval before any credit request, then create the request with an idempotency key.
+
+### Rungs considered and rejected
+| Rung | Rejected because | Missing evidence |
+|---|---|---|
+| Single agent with tools | The path does not depend on open-ended tool results; the taxonomy is fixed and enumerable (inference). Revisit if disputes need open-ended investigation. | A sample of disputes the fixed branches miss |
+| Multi-agent | None of the four needs is demonstrated: all five agents hold the same tools and context, the steps are sequential, and no context-size measurement was supplied. | Any evidence for separation of duties, parallelism, context limits, or distinct permissions |
+
+## Findings
+| ID | Severity | Area | Failure scenario | Evidence label | Fix direction | Verification step |
+|---|---|---|---|---|---|---|
+| F1 | blocking (as proposed) | Separation of duties | The reviewer agent holds the resolver's tools and context, so it agrees with the resolver's mistaken credit request and nothing independent stops it. | user-provided-sanitized-evidence | Replace the reviewer agent with a human approval before any credit request. | Confirm no credit request path exists without an approval step. |
+| F2 | condition | Durability | A dispute waits days for a customer reply while state sits in the framework's default in-memory session; a restart loses the task and the late reply has nothing to resume. | inference (verify the installed version's restart behavior) | Persist pending disputes in a durable store keyed by dispute identifier. | Kill the process mid-wait in a pilot environment and resume. |
+| F3 | condition | Loop bounds | The group chat has no round cap; two agents that disagree on classification alternate until the budget of the whole pilot is spent. | user-provided-sanitized-evidence | Drop the group chat; cap any critic step at a fixed round count. | Review the configured cap and where it is enforced. |
+| F4 | condition | Idempotency | The credit-request call has no idempotency key, so a retry after a timeout can create two requests. | user-provided-sanitized-evidence | Derive a key from the dispute identifier and the step. | Replay the same dispute twice in a pilot environment. |
+
+## Evidence and gaps
+- Design document: user-provided-sanitized-evidence.
+- Missing, not blocking: measured token counts for real disputes; a sample of disputes the fixed taxonomy misses.
+- Not reviewed here: prompt-injection paths through dispute text and the credit-request tool's authorization (security agent).
+
+## Handoffs
+- agentic-security-review-agent: designated challenger; review the recommended workflow's data reach and the credit-request path.
+
+## Decision request
+R2 with a financial flag: attach the challenge, record the deterministic workflow as the proposal and the five-agent design as the rejected alternative with its reason, preserve any dissent, and address the request to a human principal.
+```
+
+In an envelope, the verdict above is the `verdict` payload of a return message:
+
+```json
+{
+  "outcome": "simpler-pattern-sufficient",
+  "summary": "The five-agent group-chat design has no demonstrated need for multiple agents. A deterministic workflow with two model steps and a human approval before any credit request meets the stated need.",
+  "conditions": [
+    "Replace the reviewer agent with a human approval step before any credit request is created.",
+    "Persist pending disputes in a durable store so a restart does not lose a waiting task.",
+    "Derive an idempotency key from the dispute identifier and step for every credit request."
+  ]
+}
+```
+
+The handoff to the designated challenger is a separate delegate envelope. A valid objective for it is a review question, for example: "Assess whether text in a dispute record can steer the proposed workflow into creating a credit request without human approval." An imperative such as "Create the credit request" is a stop condition under the protocol, not an objective. Neither this example nor the schema proves that any approval happened; sender authentication and approval enforcement belong to the deploying runtime.

package/skills/typescript/typescript-maestro/SKILL.md

@@ -39,7 +39,7 @@ This skill makes the TypeScript Maestro a precision router. It classifies the us
 - HIGH — Distinguish, before routing: the type model of shared or published code versus a frontend application diff; module resolution and emit versus runtime execution; fleet enforcement policy versus the soundness of one construct; the TypeScript program graph versus the monorepo task graph; publication authority versus dependency intake; contract fidelity versus exploitation; advisory review versus live operation.
 - HIGH — Detect missing version evidence (compiler version, every relevant `tsconfig.json`, Node version, the exact run command, lint configuration) and refuse-and-ask for the smallest sufficient artifact set rather than guessing. This repository contains no TypeScript program of its own, so no version may ever be assumed from it.
 - HIGH — Detect production-mutation requests (publish, deploy, migrate, backfill, rotate a credential) and refuse to dispatch: this board is static-review only. Hand such requests to the named human owner together with the rollback and approval requirements. A request to *review* a mutating script is not a mutation request and routes to `typescript-business-critical-automation-governance-agent`.
-- HIGH — Route cross-domain work out of the board rather than inventing an agent for it: frontend application and framework work to `frontend-maestro-agent`; dependency intake and lockfile policy to `package-governance-agent`; the monorepo task graph to `monorepo-dx-agent`; cluster, image, and cloud runtime to the kubernetes and provider boards; artifact signing to the sigstore board; organization-wide secrets, identity, and MCP trust policy to the security board and the `mcp/` references.
+- HIGH — Route cross-domain work out of the board rather than inventing an agent for it: frontend application and framework work to `frontend-maestro-agent`; dependency intake and lockfile policy to `package-governance-agent`; the monorepo task graph to `monorepo-dx-agent`; cluster, image, and cloud runtime to the kubernetes and provider boards; artifact signing to the sigstore board; organization-wide secrets and identity to the security board; per-server MCP trust review to `agentic-security-review-agent`; organization MCP trust policy to its named human policy owner with the `mcp/` references.
 - HIGH — Decline non-TypeScript tasks (Python, Java, .NET, Kotlin, PHP, Go) and name the correct board. Do not route them through a TypeScript specialist.
 - MEDIUM — When two dispatched specialists disagree, return both verdicts with their evidence labels and name the escalation path. Never pick a winner the router has no basis to pick, and never suppress the disagreement.
 - MEDIUM — Label any reasoning offered as `documentation-based` or `inference`, and never invent a specialist that is not in the routing table.

package/skills/typescript/typescript-maestro/references/routing-taxonomy.md

@@ -8,7 +8,7 @@ The thirteen domains, the signals that select each one, and the boundaries that
 - `build-graph-performance` owns the TypeScript program graph measured with evidence; `monorepo-dx-agent` on the frontend board owns the task graph and remote caching. A request to speed something up without a measurement is a refuse-and-ask, not a dispatch.
 - `static-enforcement-policy` owns what the toolchain must prove and at what cost across packages; `type-soundness` owns whether one construct is sound. A question about which flags or lint rules the fleet must run routes to enforcement; a question about whether a specific predicate lies routes to soundness.
 - `package-publication-integrity` owns publish authority, provenance, and what ships in the tarball; dependency intake, lockfile policy, and install-time scripts belong to `package-governance-agent` on the frontend board.
-- `mcp-tool-contract` owns whether a declared MCP tool contract matches its TypeScript handler; transport, hosting, and organization MCP trust policy belong to the security board and the `mcp/` references, and vendor connectors to their own agents.
+- `mcp-tool-contract` owns whether a declared MCP tool contract matches its TypeScript handler; whether to trust a specific third-party MCP server belongs to `agentic-security-review-agent`; transport and hosting belong to the `mcp/` references; organization MCP trust policy belongs to its named human policy owner; vendor connectors belong to their own agents.
 - `engineering-economics` is never dispatched first: it consumes measurements another specialist produced and refuses to originate one. A cost question with no supplied measurements routes to the specialist who can measure it, not to economics.
 
 ## Routing table

package/skills/typescript/typescript-mcp-tool-contract/SKILL.md

@@ -25,7 +25,7 @@ This skill decides whether a declared MCP tool contract matches what its TypeScr
 ## When not to use
 
 - The question is where to host the server or which transport to use — route to the `mcp/` references and the security board.
-- The question is whether to trust a third-party MCP server — route to the security board.
+- The question is whether to trust a third-party MCP server — route to `agentic-security-review-agent`.
 - The connector is a vendor-specific product with its own agent — route to that agent.
 - The question is application-side validation unrelated to a declared MCP tool schema — route to `typescript-runtime-boundary-contract-agent`.
 - The task requires actually running or hosting the server — this skill is static-review only.