@amsterdamdatalabs/enact-extensions 0.1.12 → 0.1.25

package/extensions/enact-operator/skills/ralph/SKILL.md

@@ -1,201 +0,0 @@
----
-name: ralph
-description: "Self-referential execution loop with mandatory verification gates. Use when the user wants work completed end-to-end with fresh evidence before stopping."
-lane: true
-mcpToolPrefix: operator_ralph_
----
-
-# Ralph
-
-## Purpose
-
-`$ralph` is the persistence wrapper for Operator work. It runs a goal forward through implementation, records gate verifications, and refuses to exit until all mandatory gates pass. It is the right mode when partial completion is unacceptable and fresh evidence is required before closeout.
-
-## Use When
-
-- the user wants work shipped without a premature stop
-- verification must be recorded, not assumed
-- multiple audit gates (doctor, provider-boundary, replacement-readiness, tests) must all pass before done
-- a previous attempt left work in an incomplete or unverified state
-
-## Execution Policy
-
-- start from the repo and `.enact/operator/` truth, not chat memory
-- if `operator_*` tools are not visible yet, load/search the Enact Operator MCP namespace before doing ralph lifecycle actions
-- drive ralph through MCP tools when running inside Codex; CLI commands are the equivalent operator surface
-- keep ralph, task, inbox, and review state current as you go
-- when no external `taskId` is linked, local Operator task discipline is mandatory; Ralph owns a local task and must keep it authoritative
-- do not stop until every mandatory gate is recorded as `passed` or the loop is explicitly aborted
-
-## Routing Rules
-
-- ambiguous goal -> run `$deep-interview` first, then start ralph with the clarified goal
-- goal is clear -> start ralph immediately (MCP: `operator_ralph_start`)
-- work is blocked on an external dependency -> `operator_ralph_block` with the reason, resolve, then advance back to `running`
-- all gates pass -> `operator_ralph_complete` is allowed only from phase=verifying
-
-## Lifecycle
-
-Phases in order: `idle` -> `running` -> `verifying` -> `completed`
-
-Side exits from `running`: `blocked` (returns to `running` after resolution) or `aborted`
-
-1. Start:
-   - MCP: `operator_ralph_start` with `goal`
-   - CLI: `enact-operator ralph start "<goal>"`
-2. Implement the work while in phase `running`.
-3. Advance to verification:
-   - MCP: `operator_ralph_advance` with `toPhase=verifying`
-   - CLI: `enact-operator ralph advance verifying`
-4. Record each gate verdict:
-   - MCP: `operator_ralph_verify` with `gateId` and `status`
-   - CLI: `enact-operator ralph verify <gateId> <passed|failed> --evidence "<text>"`
-5. All gates green:
-   - MCP: `operator_ralph_complete` with `summary`
-   - CLI: `enact-operator ralph complete "<summary>"`
-6. If a gate fails: fix the underlying task, stay in phase `verifying`, re-verify.
-
-## Mandatory Gates
-
-| Gate ID                    | Name                        |
-|----------------------------|-----------------------------|
-| `doctor`                   | Operator doctor              |
-| `provider-boundary`        | Provider boundary audit     |
-| `replacement-readiness`    | Replacement readiness audit |
-| `tests`                    | Real test suite             |
-
-These four gates are present by default. Do not skip them. Each must be recorded as `passed` before `complete` is allowed.
-
-Additional rule:
-
-- if the current Ralph run also carries a `contract-parity` gate in state,
-  treat it as mandatory and resolve it through the real gate output before
-  completion. Do not fabricate parity evidence.
-
-## Workflow
-
-1. Read current state:
-   - MCP: `operator_ralph_status`
-   - CLI: `enact-operator ralph status`
-2. If no ralph is active, start one:
-   - MCP: `operator_ralph_start` with `goal`
-   - CLI: `enact-operator ralph start "<goal>"`
-3. Implement the work. Keep changes atomic and verifiable.
-4. When implementation is done, advance to `verifying`:
-   - MCP: `operator_ralph_advance` with `toPhase=verifying`, `note="Implementation complete"`
-5. Run the doctor and record:
-   - Run: `operator_doctor` (or CLI `enact-operator doctor`)
-   - Record: `operator_ralph_verify` with `gateId=doctor`, `status=passed`, `evidence="doctor output clean"`
-6. Run the provider-boundary audit and record:
-   - Run: `operator_audit_provider_boundary`
-   - Record: `operator_ralph_verify` with `gateId=provider-boundary`, `status=passed`, `evidence="<audit output>"`
-7. Run the replacement-readiness audit and record:
-   - Run: `operator_audit_replacement_readiness`
-   - Record: `operator_ralph_verify` with `gateId=replacement-readiness`, `status=passed`, `evidence="<audit output>"`
-8. Run the test suite and record:
-   - Record: `operator_ralph_verify` with `gateId=tests`, `status=passed`, `evidence="N tests passed"`
-9. If a `contract-parity` gate is present, run it through the MCP surface:
-   - `operator_contract_parity_run`
-   - use its returned status/evidence directly when recording the gate
-10. If state drift is suspected during verification, run the hygiene gate
-   through the Operator surface and fail closed on contradictions:
-   - `runStateHygieneCheck` is the underlying verifier
-   - use `operator_operator_snapshot` / `operator_hud` / `operator_workflow_reconcile`
-     to gather state evidence before recording verdicts
-11. If any verification fails: fix the root cause, do NOT fabricate evidence. Re-run and re-record.
-12. Once all four gates are `passed`:
-    - MCP: `operator_ralph_complete` with `summary`
-    - CLI: `enact-operator ralph complete "<one-line summary>"`
-13. Check HUD:
-    - MCP: `operator_hud`
-    - CLI: `enact-operator hud`
-
-## State Contract
-
-- State file: `.enact/operator/state/ralph.json`
-- Ralph reads and writes this file throughout the loop.
-- On completion, the file reflects phase=completed, all gates passed, evidence recorded.
-- On abort, phase=aborted with a reason string.
-- Do not manually edit the state file. Use the MCP tools or equivalent CLI commands.
-
-## MCP Tools
-
-The full Ralph lifecycle is exposed through the `enact-operator` MCP server:
-
-- `operator_ralph_start` — start a new ralph loop
-- `operator_ralph_status` — read current ralph state
-- `operator_ralph_advance` — transition to a new phase
-- `operator_ralph_verify` — record a gate verdict with evidence
-- `operator_ralph_pause` — pause an active loop
-- `operator_ralph_resume` — resume a paused loop
-- `operator_ralph_block` — mark blocked with a reason
-- `operator_ralph_complete` — close the loop with a summary (phase=verifying with all gates passed)
-- `operator_ralph_abort` — abort with a reason
-
-Supporting tools used during the workflow: `operator_doctor`, `operator_audit_provider_boundary`, `operator_audit_replacement_readiness`, `operator_hud`.
-
-Important:
-
-- `contract-parity` is provider-first. Operator may call the running
-  `enact-context` server surface through its adapter layer to prove declared
-  commands/events/UI/tests/hooks. That is expected and correct.
-- `state-hygiene` is no longer a stub. If it fails, Ralph should not close.
-
-## CLI Equivalents
-
-```bash
-# Start a new loop
-enact-operator ralph start "Implement provider hot-swap without downtime"
-
-# Start with explicit task links and custom gates
-enact-operator ralph start "Fix install path" --task-id abc123 --gate "lint:Lint check"
-
-# Read state
-enact-operator ralph status
-
-# Advance phase
-enact-operator ralph advance verifying --note "All code written"
-
-# Record a gate
-enact-operator ralph verify doctor passed --evidence "No errors, 3 warnings"
-enact-operator ralph verify tests failed --evidence "2 failures in suite"
-
-# Pause and resume
-enact-operator ralph pause --note "Waiting on upstream merge"
-enact-operator ralph resume --note "Upstream merged"
-
-# Block and return
-enact-operator ralph block "Cannot proceed without env var ENACT_API_KEY"
-enact-operator ralph advance running --note "Env var added"
-
-# Complete or abort
-enact-operator ralph complete "Provider hot-swap ships cleanly, all 4 gates green"
-enact-operator ralph abort "Goal invalidated by architecture change"
-```
-
-## Activation
-
-This skill is wired to Operator's UserPromptSubmit hook. When a prompt contains
-an explicit marker like `$enact-operator:ralph "<goal>"` or `$ralph "<goal>"`
-and the workspace-context hook preset is installed (verified via
-`operator_hooks_status`), the hook automatically:
-
-1. Detects the marker
-2. Starts the durable state at `.enact/operator/state/ralph.json` before the agent reads its first turn of context
-3. Adds an MCP-first context note telling the agent to load/search the Enact Operator MCP namespace immediately and continue through `operator_*` tools
-4. Records the activation in `.enact/operator/state/skill-active.json`
-
-That injected startup note is not AzDo-only. If no external `taskId` is linked, treat the local task as mandatory runtime state: read it through `operator_task_list` and keep it current throughout the run.
-
-If hooks are not installed, OR the marker did not include a goal, OR you
-want explicit control, call `operator_operator_activate` with `{skill: 'ralph',
-goal: '<goal>'}` from the MCP tool surface. The result is idempotent — if
-a ralph loop is already active, the activation is a no-op.
-
-## Final Check
-
-- Phase is `completed`, not `running` or `verifying` (check via `operator_ralph_status`).
-- All four mandatory gates show `passed` in the ralph state.
-- Every gate has non-empty evidence text — not a placeholder.
-- `operator_hud` shows no active ralph loop outstanding.
-- No fabricated evidence. Each gate result comes from a real command run.

package/extensions/enact-operator/skills/ralph/gemini.md

@@ -1,18 +0,0 @@
-# Ralph (Gemini Variant)
-
-You are running Ralph with a Gemini model identity.
-
-Keep the same durable runtime contract as the default Ralph skill:
-
-- drive the goal to completion with real state updates
-- record evidence for every mandatory gate
-- fail closed when evidence is missing or contradictory
-- do not claim completion until all required gates are passed
-
-## TOOL_CALL_MANDATE
-
-- keep tool usage explicit, short, and sequential
-- prefer direct MCP/tool results over narrative summaries
-- when a gate depends on a command or runtime check, run it first and cite the result
-- if a required tool is not visible, load/search the operator MCP namespace before continuing
-- do not substitute inferred status for tool-backed evidence

package/extensions/enact-operator/skills/ralplan/SKILL.md

@@ -1,151 +0,0 @@
----
-name: ralplan
-description: "Plan-first Operator execution wrapper: write a durable plan, enter the Ralph loop, drive to verified completion."
-lane: true
-mcpToolPrefix: operator_ralplan_
----
-
-# Ralplan
-
-## Purpose
-
-Use `$ralplan` when the work needs a reviewable execution plan before the Ralph loop starts. Ralplan is the disciplined alternative to `$autopilot` — it gates execution behind a plan the user or reviewer can inspect, then advances into Ralph's self-referential loop with explicit verification checkpoints.
-
-Ralplan is the combination of `$plan` (write artifacts, define slices and verification) and `$ralph` (durable execution loop with phase gates). Neither sub-skill is optional.
-
-## Use When
-
-- The request is clear enough to plan but carries meaningful risk or complexity
-- A written plan artifact needs to exist before any code changes
-- Verification gates need to be defined up front, not discovered mid-execution
-- The user wants to review the plan before execution begins
-
-## Do Not Use When
-
-- The request is still ambiguous — route through `$deep-interview` first, then return here
-- The work is trivial and a plan would add no value
-- The user explicitly wants unattended delivery without a plan review — use `$autopilot`
-
-## Execution Policy
-
-- start from the repo and `.enact/operator/` truth, not chat memory
-- drive the workflow through MCP tools when running inside Codex; CLI commands are the equivalent operator surface
-- keep ralph, task, and review state current as you go
-- do not advance to the Ralph loop before the plan artifact exists and is reviewed
-
-## Lifecycle
-
-```
-intent → $plan (write plan + verification map) → user review → $ralph start → running → verifying → completed
-```
-
-Each transition is explicit. Never advance to the Ralph loop before the plan artifact exists and is reviewed.
-
-## Workflow
-
-### Phase 1 — Plan
-
-1. Read current Operator artifacts:
-   - MCP: `operator_session_status`, `operator_state_read`
-   - CLI:
-     ```
-     enact-operator session status
-     enact-operator state read
-     ```
-2. Write the plan to `.enact/operator/plans/<phase>.md` following `$plan` conventions:
-   - Named files per slice
-   - Explicit verification per slice
-   - Exit conditions stated
-3. Write the verification map to `.enact/operator/plans/<phase>-verification.md`.
-4. Link the plan artifact to ultrawork if an ultrawork session is active:
-   - MCP: `operator_ultrawork_link_plan` with the plan id
-5. Present the plan for review. Do not advance until it is approved.
-
-### Phase 2 — Execute
-
-6. Start the Ralph loop with the goal and verification gates from the plan:
-   - MCP: `operator_ralph_start` with `goal`
-   - CLI: `enact-operator ralph start "<goal>" --gate g1:"<Gate Name>" --gate g2:"<Gate Name>"`
-7. Confirm Ralph is running:
-   - MCP: `operator_ralph_status`
-   - CLI: `enact-operator ralph status`
-8. Execute each plan slice. After each slice, record evidence:
-   - MCP: `operator_ralph_verify` with `gateId` and `status=passed`
-   - CLI: `enact-operator ralph verify <gateId> passed --evidence "<evidence text>"`
-9. If blocked, record the blocker and pause:
-   - MCP: `operator_ralph_block` with reason, then `operator_ralph_pause`
-   - CLI:
-     ```
-     enact-operator ralph block --note "<reason>"
-     enact-operator ralph pause
-     ```
-   Resolve the block, then resume:
-   - MCP: `operator_ralph_resume`
-   - CLI: `enact-operator ralph resume`
-
-### Phase 3 — Verify and Complete
-
-10. When all gates have evidence, advance to the verifying phase:
-    - MCP: `operator_ralph_advance` with `toPhase=verifying`
-    - CLI: `enact-operator ralph advance verifying`
-11. Run `$review` against the completed work and plan artifacts.
-12. If review passes, complete the Ralph session:
-    - MCP: `operator_ralph_complete` with `summary`
-    - CLI: `enact-operator ralph complete`
-13. If review returns changes requested, advance back to running and address findings:
-    - MCP: `operator_ralph_advance` with `toPhase=running`
-    - CLI: `enact-operator ralph advance running --note "<what changed>"`
-
-## State Contract
-
-Reads:
-- `.enact/operator/plans/` (plan and verification map written in Phase 1)
-- `.enact/operator/state/ralph-state.json` (Ralph loop state)
-
-Writes:
-- `.enact/operator/plans/<phase>.md`
-- `.enact/operator/plans/<phase>-verification.md`
-- Ralph state via MCP tools or CLI commands
-
-## MCP Tools
-
-- `operator_session_status` — read current session state
-- `operator_state_read` — read active operator state
-- `operator_ralph_start` — start a new ralph loop with goal and gates
-- `operator_ralph_status` — read current ralph state
-- `operator_ralph_advance` — transition to a new phase
-- `operator_ralph_verify` — record a gate verdict with evidence
-- `operator_ralph_block` — mark blocked with a reason
-- `operator_ralph_pause` — pause the active loop
-- `operator_ralph_resume` — resume a paused loop
-- `operator_ralph_complete` — close the loop with a summary
-- `operator_ralph_abort` — abort the loop with a reason
-- `operator_ultrawork_link_plan` — link the plan artifact to an active ultrawork session
-
-## Commands
-
-```
-enact-operator session status
-enact-operator state read
-enact-operator ralph start "<goal>" --gate <id>:<name>
-enact-operator ralph status
-enact-operator ralph advance <phase>
-enact-operator ralph verify <gateId> passed --evidence "<text>"
-enact-operator ralph verify <gateId> failed --evidence "<text>"
-enact-operator ralph block --note "<reason>"
-enact-operator ralph pause
-enact-operator ralph resume
-enact-operator ralph complete
-enact-operator ralph abort
-```
-
-## Activation
-
-When a prompt contains `$enact-operator:<skill-name>` or `$<skill-name>`, Operator's UserPromptSubmit hook records the invocation in `.enact/operator/state/skill-active.json` and adds an MCP-first context note for the agent. That note tells the agent to load/search the Enact Operator MCP namespace immediately if `operator_*` tools are not visible yet, then prefer `operator_*` tools over the `enact-operator` CLI. This skill is operator-driven — there is no durable workflow state to start automatically. The activation log gives operators and the HUD a trace of which skills were explicitly invoked.
-## Final Check
-
-- Plan artifact exists at `.enact/operator/plans/<phase>.md` before Ralph was started
-- All verification gates have evidence recorded, not just a passed status
-- `$review` verdict is approved
-- `operator_ralph_status` shows phase as `completed`
-- No stale Ralph state file remains active under `.enact/operator/state/`

package/extensions/enact-operator/skills/remove-deadcode/SKILL.md

@@ -1,45 +0,0 @@
----
-name: remove-deadcode
-description: "LSP-verified symbol deletion with entry-point guards and candidate-parallel execution."
----
-
-# Remove Deadcode
-
-## Purpose
-
-Use `$remove-deadcode` to remove provably unused code symbols without damaging runtime entry points.
-
-## Preconditions
-
-- collect candidate symbols before any deletion
-- load optional entry-point guard list from `.enact/operator/remove-deadcode/entry-points.txt`
-
-## Required Safety Contract
-
-For each candidate symbol, the deletion gate is strict:
-
-1. If symbol is listed in the entry-point guard file, skip deletion unconditionally.
-2. Otherwise call `lsp_find_references` (via enact-context).
-3. If references are non-empty, abort deletion for that symbol and emit an explanatory message.
-4. Only delete when references are exactly zero and the symbol is not guarded.
-
-## Execution Model
-
-- batching is explicit: enumerate all candidates first
-- then dispatch parallel `executor` subagents, one candidate per subagent
-- each subagent must apply the same guard-list and `lsp_find_references` checks
-
-## Behavioral Constraints
-
-- no heuristic-only deletion
-- no bypass of entry-point guard list
-- no GitHub-specific assumptions or workflows in deletion decisions
-
-## Verification Expectations
-
-- unit test: non-empty `lsp_find_references` result must refuse deletion
-- unit test: guard-listed symbol must be skipped even when reference count is zero
-
-## Activation
-
-When a prompt contains `$enact-operator:<skill-name>` or `$<skill-name>`, Operator's UserPromptSubmit hook records the invocation in `.enact/operator/state/skill-active.json` and adds an MCP-first context note for the agent. That note tells the agent to load/search the Enact Operator MCP namespace immediately if `operator_*` tools are not visible yet, then prefer `operator_*` tools over the `enact-operator` CLI. This skill is operator-driven — there is no durable workflow state to start automatically. The activation log gives operators and the HUD a trace of which skills were explicitly invoked.

package/extensions/enact-operator/skills/research/SKILL.md

@@ -1,74 +0,0 @@
----
-name: research
-description: "Evidence-first research mode for current patterns, implementation risks, and decision support."
----
-
-# Research
-
-## Purpose
-
-Use `$research` when the correct implementation depends on facts you do not yet have, either from the repo or from current external sources.
-
-## Execution Policy
-
-- start with brownfield evidence from the repo
-- use primary sources for technical questions
-- end with a decision-ready recommendation, not a wall of notes
-- persist findings so the next pass does not repeat the work
-
-## Workflow
-
-1. Identify the actual unknowns.
-2. Separate:
-   - repo truth
-   - external truth
-   - assumptions
-3. Gather only the evidence needed to decide.
-4. Write the result into `.enact/operator/research/summary.md`.
-5. Update any linked ultrawork or task state if the research is part of an active execution lane.
-
-## Parallel Sweep
-
-Run concurrent research agents for independent evidence lanes. The floor is 2 concurrent agents whenever there are both repo-truth and external-truth unknowns.
-
-- minimum concurrent-agent floor: 2
-- recommended split: one agent for internal repo evidence and one agent for external primary sources
-- increase concurrency only when unknowns are independent and synthesis cost remains manageable
-
-Anti-stop rule: do not stop at the first result. Continue each lane until at least one corroborating source is collected per lane, or until an explicit blocker is documented.
-
-## Runtime Clarification
-
-- `$research` is an evidence pass, not a currently exposed closure-owning
-  runtime lane.
-- If research output is being used to support closure on a live task, rely
-  on the real Operator proof surfaces rather than treating research notes as
-  equivalent to parity evidence:
-  - `operator_contract_parity_run`
-  - `operator_workflow_reconcile`
-  - `operator_operator_snapshot`
-
-## Deliverables
-
-- current pattern or contract summary
-- risk list
-- recommendation with concrete tradeoffs
-- open questions that still block planning or execution
-
-### Internal Evidence
-
-- repo paths inspected
-- commands or tools used
-- concrete findings tied to files, code, or runtime state
-- unresolved internal gaps
-
-### External Evidence
-
-- primary sources consulted
-- dated facts and version-sensitive constraints
-- corroboration across at least one additional source
-- unresolved external gaps
-
-## Activation
-
-When a prompt contains `$enact-operator:<skill-name>` or `$<skill-name>`, Operator's UserPromptSubmit hook records the invocation in `.enact/operator/state/skill-active.json` and adds an MCP-first context note for the agent. That note tells the agent to load/search the Enact Operator MCP namespace immediately if `operator_*` tools are not visible yet, then prefer `operator_*` tools over the `enact-operator` CLI. This skill is operator-driven — there is no durable workflow state to start automatically. The activation log gives operators and the HUD a trace of which skills were explicitly invoked.

package/extensions/enact-operator/skills/review/SKILL.md

@@ -1,58 +0,0 @@
----
-name: review
-description: "Findings-first pre-landing review against code, plan completion, verification evidence, and durable runtime state."
----
-
-# Review
-
-## Purpose
-
-Use `$review` to answer one question: is this actually ready to land? Review is not a summary pass. It is a bug, regression, coverage, and state-integrity pass.
-
-## Execution Policy
-
-- findings first, summary second
-- prefer evidence over author claims
-- check the code, the tests, the plan, and the runtime artifacts
-- if the current context authored the change, prefer a separate reviewer role for approval
-
-## Review Order
-
-1. Read the changed code.
-2. Read the active plan and verification map.
-3. Check what was supposed to happen vs what actually landed.
-4. Verify:
-   - tests and typechecks
-   - docs drift
-   - `.enact/operator/` state drift
-   - task, review, inbox, and ledger accuracy
-5. Produce a verdict:
-   - approved
-   - changes requested
-   - blocked
-
-## Mandatory Checks
-
-- missing or fake verification
-- uncovered changed paths
-- stale docs or setup instructions
-- task marked done but still pending review evidence
-- runtime claiming health while inbox or review queue says otherwise
-
-## Recommended State Reads
-
-- `operator_reviews_list`
-- `operator_inbox_list`
-- `operator_ledger_recent`
-- `operator_hud`
-
-## Output Standard
-
-- findings ordered by severity
-- file references and why they matter
-- residual risk
-- final verdict and next action
-
-## Activation
-
-When a prompt contains `$enact-operator:<skill-name>` or `$<skill-name>`, Operator's UserPromptSubmit hook records the invocation in `.enact/operator/state/skill-active.json` and adds an MCP-first context note for the agent. That note tells the agent to load/search the Enact Operator MCP namespace immediately if `operator_*` tools are not visible yet, then prefer `operator_*` tools over the `enact-operator` CLI. This skill is operator-driven — there is no durable workflow state to start automatically. The activation log gives operators and the HUD a trace of which skills were explicitly invoked.

package/extensions/enact-operator/skills/security-research/SKILL.md

@@ -1,54 +0,0 @@
----
-name: security-research
-description: "Multi-agent security research with hunter/PoC split and optional critical bug auto-creation in Azure DevOps."
----
-
-# Security Research
-
-## Purpose
-
-Use `$security-research` to run a focused vulnerability hunt, produce ranked findings, and optionally create Azure DevOps Bug work items for critical issues.
-
-## Parameters
-
-- `autoCreateBugs: boolean` (default `true`)
-- when `false`, no `factory_workitem_sync_once` call is allowed regardless of severity
-
-## Team Topology
-
-- 3 hunter agents:
-- hunter 1: CWE classification
-- hunter 2: CVSS v4 scoring
-- hunter 3: OWASP category mapping
-- 2 PoC engineer agents:
-- PoC 1 and PoC 2: exploitability proof and reproduction quality
-
-## Required Workflow
-
-1. Launch hunters to identify and classify potential vulnerabilities.
-2. Launch PoC engineers on top-ranked findings to validate exploitability.
-3. Merge outputs into a single findings report.
-4. Write report to `.enact/operator/security/<sessionId>/findings.md`.
-5. Rank findings in the report by CVSS v4 severity.
-6. For each finding with CVSS v4 `>= 9.0`, if `autoCreateBugs=true`, call `factory_workitem_sync_once` to create a `Bug` work item.
-7. If `autoCreateBugs=false`, skip all bug auto-creation calls.
-
-## Azure DevOps-Only Contract
-
-- use factory MCP work-item surfaces for bug creation
-- no GitHub Security Advisories, GitHub issue creation, or GitHub-specific security automation assumptions
-
-## Behavioral Constraints
-
-- CVSS scoring must be v4, not v3 fallback
-- critical auto-bug creation threshold is fixed at `>= 9.0`
-- findings must include at least one of: CWE, CVSS v4 vector/score, OWASP mapping
-
-## Verification Expectations
-
-- integration test: findings report includes at least one CWE classification entry
-- integration test: with `autoCreateBugs=false`, verify no `factory_workitem_sync_once` call is made
-
-## Activation
-
-When a prompt contains `$enact-operator:<skill-name>` or `$<skill-name>`, Operator's UserPromptSubmit hook records the invocation in `.enact/operator/state/skill-active.json` and adds an MCP-first context note for the agent. That note tells the agent to load/search the Enact Operator MCP namespace immediately if `operator_*` tools are not visible yet, then prefer `operator_*` tools over the `enact-operator` CLI. This skill is operator-driven — there is no durable workflow state to start automatically. The activation log gives operators and the HUD a trace of which skills were explicitly invoked.