Update to Tahr Security

{
  "name": "tahr-verify-security-fix",
  "description": "Retest a security fix in the exact vulnerable context, decide whether the exploit path is closed, and validate secure remediation and regression coverage without breaking legitimate behavior. Use after a vulnerability patch, remediation commit, PR fix, dependency or configuration change, failed security retest, or when developers need proof that a fix is complete rather than a superficial code change.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 270
    },
    {
      "relative_path": "references/exact-context-retest-verdicts.md",
      "size_in_bytes": 5141
    },
    {
      "relative_path": "references/remediation-and-regression-gates.md",
      "size_in_bytes": 4661
    }
  ],
  "skill_md_contents": "---\nname: tahr-verify-security-fix\ndescription: Retest a security fix in the exact vulnerable context, decide whether the exploit path is closed, and validate secure remediation and regression coverage without breaking legitimate behavior. Use after a vulnerability patch, remediation commit, PR fix, dependency or configuration change, failed security retest, or when developers need proof that a fix is complete rather than a superficial code change.\n---\n\n# Tahr Verify Security Fix\n\nVerify the failed security control and the attacker outcome, not merely the\npresence of a patch. Preserve the original finding, proof, context, and scope so\na different identity, tenant, route, payload, deployment, or render path cannot\nproduce a false pass.\n\n## Establish retest authority and safety\n\n1. Record the original finding ID, exact claim, required proof, original\n   positive evidence, affected revision, fix revision, and supplied patch.\n2. Record the original actor/role, owner/tenant/object, endpoint or workflow,\n   method/content type, payload class, state, configuration, render/trigger\n   context, and final impact.\n3. Default to source and test inspection. Exercise only an explicitly\n   authorized local or staging target. Do not infer permission for production,\n   third-party, destructive, credential-changing, billing, or broad data tests.\n4. Use disposable accounts and fixtures. Preserve protected identities and\n   extract only the minimum proof sample.\n5. Redact passwords, cookies, bearer/session tokens, API keys, private keys,\n   reset codes, personal data, and customer data. Retain only type, location,\n   and hash/fingerprint when necessary.\n\nRead [exact-context-retest-verdicts.md](references/exact-context-retest-verdicts.md)\nand create separate candidate, proof, and coverage records before testing.\n\n## Inspect the remediation\n\nTrace the original source-to-sink or missing-control path through current code.\nIdentify:\n\n- the exact failed control and where the patch now enforces it;\n- existing project policy, ownership/tenant scope, validator, sanitizer,\n  encoder, parameter binding, allowlist, network guard, or safe API reused;\n- adjacent route, resolver, service, repository, serializer, worker, webhook,\n  content type, method, redirect, or render path that may bypass the fix;\n- public behavior, auth semantics, tenant rules, response shape, data\n  invariants, and framework lifecycle that must remain compatible.\n\nSearch for a concrete contradiction to the fix claim. A new helper, regex, test,\nor guard name is not proof that the effective path uses it.\n\n## Retest in the exact context\n\n1. Reproduce the original benign baseline.\n2. Replay the original exploit or closest safe equivalent using the original\n   actor, ownership/tenant relation, route, content type, state, and trigger.\n3. Confirm the expected denial, encoding, validation, scoped result, blocked\n   network/file action, safe query, or non-execution result.\n4. Read back durable state or observe the final sink. Do not stop at the first\n   accepting or rejecting layer.\n5. Run a positive control proving the legitimate owner, tenant, role, input, or\n   workflow still succeeds.\n6. Run class-relevant alternate encodings, methods, content types, object IDs,\n   roles, tenant relationships, render contexts, redirects, or concurrency\n   variants within the safe budget.\n7. Test sibling paths that share the changed control.\n\nUse fresh, identity-matched sessions and prove object/tenant ownership for\nauthorization retests. A `200`, body-size change, reflection, upload acceptance,\ntool success flag, timeout, stale session, or WAF response is not a retest\nverdict by itself.\n\n## Assign an exact verdict\n\nAssign one verdict from the reference contract:\n\n- `FIX_VERIFIED`;\n- `FIX_PARTIAL`;\n- `NOT_FIXED`;\n- `REGRESSION_INTRODUCED`;\n- `INCONCLUSIVE`.\n\nSupport it with finding-local positive evidence, negative evidence, controls\ntested, contradiction result, exact-context match, variants, limitations, and\nfinal basis. Tooling or environment failure alone requires `INCONCLUSIVE`, not\na pass or failure.\n\n## Remediate securely when authorized\n\nIf the user asks only for verification, report the defect and do not edit. If\nthe user also asks to fix it, read\n[remediation-and-regression-gates.md](references/remediation-and-regression-gates.md)\nand:\n\n1. Localize only real repository files, symbols, routes, controls, and tests.\n2. Repair the failed control at the smallest correct shared layer.\n3. Reuse established project security primitives before creating parallel\n   logic.\n4. Avoid blacklist/regex-only fixes when parameterized, encoded, scoped,\n   schema-validated, or allowlisted APIs exist.\n5. Preserve public behavior except for the intentional rejection of the\n   vulnerable action.\n6. Add a regression test that fails on the vulnerable behavior and a positive\n   control for legitimate behavior.\n7. Run focused tests first, then feasible lint, type, build, integration, and\n   broader tests.\n8. Review the final diff for adjacent bypasses, superficial controls, generated\n   edits, unrelated churn, secret leakage, and compatibility breaks.\n\nDo not mark the fix ready because a test was added; confirm the test reaches\nthe original sink or protected action and fails without the effective control.\n\n## Account for coverage and conclude\n\nAccount for the original path, every material alternate path, sibling consumer,\nsecurity-relevant variant, required negative control, legitimate positive\ncontrol, and test command. Give unresolved high-risk rows an exact blocker and\nowner.\n\nDo not issue `FIX_VERIFIED`, “ready,” or a clean conclusion while an original\nproof element is missing, the exact context was not reproduced, a high-risk\nbypass path is unreviewed, required tests did not run, or a material regression\nremains. Use `FIX_PARTIAL`, `REGRESSION_INTRODUCED`, or `INCONCLUSIVE` and state\nthe next evidence needed.\n"
}