Update to codex-sdlc

{
  "description": "Use when an active SDLC run needs feature requirements, typed fact-to-claim reconciliation, user stories, acceptance criteria, business rules, validation, edge cases, assumptions, open questions, or traceability.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 207
    },
    {
      "relative_path": "references/output-example.md",
      "size_in_bytes": 3650
    },
    {
      "relative_path": "references/requirements-contract.md",
      "size_in_bytes": 3571
    },
    {
      "relative_path": "references/role-contract.md",
      "size_in_bytes": 2035
    }
  ],
  "name": "sdlc-ba",
  "skill_md_contents": "---\nname: sdlc-ba\ndescription: Use when an active SDLC run needs feature requirements, typed fact-to-claim reconciliation, user stories, acceptance criteria, business rules, validation, edge cases, assumptions, open questions, or traceability.\n---\n\n# SDLC Business Analysis\n\nFor a saved Compact run, follow the [Compact specification path](../sdlc-pm/references/compact-workflow.md): author one semantic specification through `compact-spec`, and let the runtime derive fact claims and acceptance views. The seven-document envelope below applies to Full/legacy evaluator work. Compact still requires approved facts, complete acceptance coverage, and PM review; never silently omit unresolved facts.\n\nKeep business requirements tied to real user outcomes. Runtime 1.0.0 allows several distinct technical capabilities to reference the same `REQ-*`; do not split or renumber requirements merely to satisfy the five backend capability slots. Fact/claim reconciliation and acceptance traceability remain required.\n\nCreate reviewable requirements from the run's typed facts; Product Owner and PM approval remain separate decisions.\n\n1. Read the active run manifest, assigned BA task, immutable request, PM intake artifacts including `facts.yaml`, `.sdlc/project.yaml`, applicable `AGENTS.md`, policies, workflow, and templates. If project documentation is configured in another repository, resolve `resources.documentation` through `.sdlc/local.yaml`; cite it as source material while keeping authoritative BA run artifacts in the coordinator repository.\n2. Read [role contract](references/role-contract.md), [requirements contract](references/requirements-contract.md), and [output example](references/output-example.md).\n3. Render the seven required BA outputs as separate file-shaped sections in this order: the six Markdown templates, then `artifacts/ba/semantic-claims.yaml`. Give every Markdown artifact its own exact metadata block.\n4. Treat `facts.yaml` as the deterministic input truth. Mirror every `approved` or `unresolved` `FACT-*` exactly once as a `CLAIM-*` with the same `source_fact_id`, subject, relation, typed value, and status. Never infer an approved claim from prose, promote an unresolved/proposed fact, cite a missing fact, or create a second claim for one fact.\n5. Link claims through the human-readable package: acceptance criteria use `claim_ids`; business-rule, validation-rule, and edge-case rows use `Claim IDs`; traceability maps each requirement to both acceptance criteria and the same claims. A referenced claim must include that row's `REQ-*` in `requirement_ids`.\n6. Use stable `REQ-*`, `AC-*`, `BR-*`, `VAL-*`, `EDGE-*`, `CLAIM-*`, `ASM-*`, and `Q-*` IDs. Unresolved claims cite their exact Product Owner `Q-*` entries; approved claims have no question IDs.\n7. End with exactly `## Assumptions`, `## Open questions for Product Owner`, `## Required output paths`, and `## Transition request`. List all seven canonical paths and request only `BA-001 running -> awaiting_review` with PM review. Never request or claim `completed`.\n\nStructured claims are authoritative when explanatory prose conflicts with them. Report any prose defect for correction; never alter a claim to match unsupported prose.\n\nNever modify product code, the manifest, facts, policy, schema, workflow, template, or approval state. Never self-approve requirements.\n\n## Red flags — stop and repair\n\n- Fewer or more than seven artifact sections, a preface, or trailing prose\n- Missing, duplicate, invented, promoted, or structurally changed fact claim\n- Rule-bearing entry without a compatible claim and traceability link\n- Unresolved claim without a Product Owner question\n- Combined artifact, renamed template column, unstable ID, or malformed YAML\n- Any transition other than the PM-review `awaiting_review` handoff\n"
}