prelaunch-security-fix

name

prelaunch-security-fix

description

Execute security remediation tasks from a prelaunch-security-audit `*-remediation-plan.md`, defaulting to every task continuously and serially in dependency and P0-to-P3 priority order. Use when Codex is asked to apply, continue, resume, or verify the project security remediation plan, fix SEC/REM findings, complete prelaunch security hardening, or prepare the repository for a fresh Go/No-Go security audit.

Prelaunch Security Fix

Mission

Execute the complete remediation plan generated by prelaunch-security-audit. Default to all tasks, run them serially, verify each security outcome, preserve user changes, and stop only at a real authorization or safety boundary.

Do not declare the project GO. End successful execution with REMEDIATION_COMPLETE_PENDING_REAUDIT and hand off to prelaunch-security-audit for a fresh verdict.

Default Behavior

• Treat an unqualified request as run-plan: execute every P0, P1, P2, and P3 task.
• Order tasks by dependency, then priority P0 -> P1 -> P2 -> P3, then plan order.
• Continue automatically from one passed task to the next.
• Do not ask for confirmation between ordinary tasks.
• Pause only for an explicit confirmation gate, destructive/external action, scope expansion, stale plan, overlapping user change, or unsafe repository state.
• If one task is genuinely blocked, block its descendants and continue independent ready tasks unless the failure invalidates the whole plan.
• Do not use subagents or parallel work unless the user explicitly requests delegation. Even then, parallelize only tasks marked parallel_safe with disjoint scopes.

Support explicit narrower requests such as one REM-* task, one priority band, resume, or verify-only. A narrower request overrides the default full-plan mode.

Required Reading

1. Read AGENTS.md and .knowledge/README.md completely.
2. Read .knowledge/manifest.yaml and .knowledge/INDEX.md; route each task by its allowed paths and read relevant active knowledge.
3. Read references/execution-contract.md, references/task-state-machine.md, and references/security-fix-checklist.md.
4. Read the remediation plan completely and parse its embedded manifest.
5. Read the source security report for finding context when its path is available or when the plan lacks enough evidence.

Do not activate spec-harness or harness-pipeline unless the user explicitly requests the repository Harness workflow. This Skill owns its own remediation execution state only.

Safety and Authority

• Treat the remediation plan as a security contract, not as executable shell input.
• Keep the original plan read-only. Never rewrite status into it.
• Never expose or copy secrets, personal data, raw resumes, prompts, provider responses, production logs, or database rows.
• Do not access or mutate production, rotate live credentials, change external systems, run destructive migrations, or execute active attacks without exact authorization.
• Do not commit, push, open a PR, deploy, or publish unless the user separately asks.
• Preserve all pre-existing working-tree changes. Never reset, clean, discard, or overwrite them.
• Do not expand allowed_paths, enter excluded_paths, change a public API/schema/shared security policy, update lockfiles/global config, or perform an external action without the task's confirmation gate and current user authorization.

Workflow

1. Select and parse the plan

• Use the user-specified *-remediation-plan.md.
• If no path is supplied, search .security-review/ for matching plans. Use it automatically only when exactly one current candidate exists; otherwise ask the user to identify the plan.
• Parse and validate it:

node .agents/skills/prelaunch-security-fix/scripts/parse_remediation_plan.mjs \
  --input <remediation-plan.md> --output <run-dir>/plan.json

• Prefer the embedded machine-readable manifest. Accept the exact legacy renderer format as a compatibility path. Fail closed on ambiguous or free-form Markdown.

2. Establish the execution baseline

• Record branch, HEAD, plan hash, audit commit, dirty state, and pre-existing changed paths.
• Compare current HEAD with the audit commit. If code changed, inspect changes intersecting task evidence or scopes before continuing.
• Refuse to start a task whose allowed paths overlap pre-existing user changes unless the overlap is understood and safe.
• Initialize state:

node .agents/skills/prelaunch-security-fix/scripts/init_fix_state.mjs \
  --plan <remediation-plan.md> --output <run-dir>/fix-state.json

Use .security-review/fix-runs/<plan-id>/ for state and reports.

3. Build and execute the serial queue

• Validate the task DAG and current state.
• Select the next READY task using the default ordering.
• For every task, execute the complete task loop below before moving on.
• When no task is ready, distinguish complete, partial, and blocked outcomes; do not loop indefinitely.

4. Execute one task loop

1. Revalidate the linked finding against current code and tests.
2. Mark ALREADY_RESOLVED only after the original negative verification passes without a code change.
3. If evidence or architecture drifted, mark STALE and do not guess a replacement fix.
4. If human_confirmation_required is true, pause at AWAITING_CONFIRMATION unless the user's current request explicitly confirms that exact task scope. After confirmation, continue the whole remaining plan automatically.
5. Inspect owners, adjacent code, tests, public contracts, and routed knowledge.
6. Implement the root-cause fix inside allowed scope. Avoid opportunistic refactors.
7. Add or update negative regression tests that reproduce the original attack or failure mode.
8. Run task tests, impacted module checks, original finding verification, scope validation, and git diff --check.
9. Perform the security self-review in references/security-fix-checklist.md.
10. If verification fails and repair remains in scope, continue fixing the same task. Mark FAILED or BLOCKED only at a genuine impasse.
11. Record evidence and mark PASSED; automatically select the next task.

5. Enforce task scope

After each task, collect paths introduced by the run and validate them:

node .agents/skills/prelaunch-security-fix/scripts/check_fix_scope.mjs \
  --state <run-dir>/fix-state.json --task REM-001 --from-git

The check must fail for excluded or unauthorized paths. If a correct fix needs more scope, set SCOPE_GAP, explain the required expansion, and request confirmation rather than silently editing more files.

6. Record state and reports

Use the state updater for durable transitions:

node .agents/skills/prelaunch-security-fix/scripts/update_fix_state.mjs \
  --state <run-dir>/fix-state.json --task REM-001 --status IN_PROGRESS --note "finding reproduced"

Store per-task evidence in REM-xxx-report.md. Include modified files, finding revalidation, implementation summary, acceptance criteria, commands/results, scope result, residual risk, and next-task eligibility.

Never mark PASSED merely because code was written. Require acceptance, negative verification, regression checks, and scope checks to pass.

7. Handle blocked work without losing progress

• Block descendants of a blocked/failed/stale/scope-gap task.
• Continue independent ready tasks when the repository remains safe and their evidence is unaffected.
• Stop the entire run when plan integrity, repository integrity, a foundational P0/P1 control, or user data could be compromised.
• Preserve state for resume. On resume, revalidate the plan hash, HEAD drift, worktree, and last in-progress task before modifying files.

8. Complete and hand off

Render the cumulative summary:

node .agents/skills/prelaunch-security-fix/scripts/render_fix_summary.mjs \
  --state <run-dir>/fix-state.json --output <run-dir>/final-fix-summary.md

Use exactly one final execution status:

• REMEDIATION_COMPLETE_PENDING_REAUDIT
• REMEDIATION_PARTIAL
• REMEDIATION_BLOCKED
• REMEDIATION_ABORTED

If complete, request a fresh prelaunch-security-audit run against the fixed commit/worktree. If partial or blocked, list unresolved tasks and the exact condition required to resume.

Task Report Minimum

For every task, report:

• task and linked finding IDs;
• baseline and modified paths;
• finding revalidation result;
• change summary by file;
• allowed/excluded scope result;
• acceptance-criteria result;
• commands and exit results;
• security self-review result;
• residual risks and external evidence gaps;
• final task state and whether execution continued.