configure_wave_gate

[SUPPORT] 74a8f420 — PLANNING: configure (or on-the-fly reconfigure) a deterministic action pipeline attached to a wave or wave-range, ENFORCED STRUCTURALLY — not just advisory /goal prose. Once set, claim_sprint_item refuses (WAVE_GATE_PENDING) to claim any item whose wave sorts beyond wave_end until complete_wave_gate records real run_verification evidence for that boundary. actions is an ordered, non-empty list of {"type": ...} dicts — type must be one of push_dev | push_main | deploy | wait | run_verification (push_dev/push_main/deploy are run by the executor via trigger_workflow; run_verification maps onto the run_verification tool whose output complete_wave_gate requires as evidence; wait is a plain pause step; extra keys per action, e.g. {"type": "wait", "seconds": 30}, are preserved verbatim). wave_start (defaults to wave_end) documents a multi-wave range covered by one gate checkpoint. Re-configuring an un-passed wave_end is an upsert — the pipeline can be revised right up until an executor completes it; once passed the config is immutable (returns {"error": ...}). Returns {configured, gate_config_id, project_id, wave_start, wave_end, actions} on success. ed8e4524 — SCOPED TO SPRINT VERSION: pass version (or session_id to auto-resolve the calling session's scope) so two different sprint versions that happen to share the SAME wave_end label never reconfigure or immutably block each other's gate — omit both to keep the exact prior project-wide behavior for a single-version project. Persistent-state disclosure: on hosted Meridian, supplied text and project/session metadata -- including task log entries, pinned decisions, sprint items, notes, handoff/goal state, and HITL queue items -- are sent to and stored in Meridian's service, in an isolated per-tenant Postgres database (Neon); self-hosted deployments keep the same categories in the configured local SQLite/Postgres database. This data is visible in the dashboard and API, and may resurface in later project context or handoffs. Notes and pinned decisions can be deleted individually; task log entries and sprint items can be deleted via the dashboard/API (not exposed as an agent-facing tool); HITL queue items and handoff state have no per-record delete. Full removal of any of this data is available via project or account deletion, using the documented controls. Do not include secrets. It is categorised as a Write tool in the Meridian MCP Server, which means it can create or modify data. Consider rate limits to prevent runaway writes.

configure_wave_gate accepts 8 parameters: actor, actions, version, wave_end, project_id, session_id, wave_start, project_name. Required: actions, wave_end. The full parameter table on this page comes from the server's own tool schema.

Register the Meridian MCP server in PolicyLayer and add a rule for configure_wave_gate: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Meridian. Nothing to install.

configure_wave_gate is a Write tool with medium risk. Write tools should be rate-limited to prevent accidental bulk modifications.

Yes. Add a rate_limit block to the configure_wave_gate rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.

Set action: deny in the PolicyLayer policy for configure_wave_gate. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.

configure_wave_gate is provided by the Meridian MCP server (@meridianmcp/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.