Update to Development OS

{
  "description": "Automatically use whenever development work depends on proof, uncertainty, tests, runtime/provider evidence, documentation authority, regressions, acceptance, or deciding what evidence deserves permanence. Manage the transition from uncertainty to justified confidence and preserve durable guarantees without turning every probe into infrastructure.",
  "included_files": [],
  "name": "evidence-stewardship",
  "skill_md_contents": "---\nname: evidence-stewardship\ndescription: \"Automatically use whenever development work depends on proof, uncertainty, tests, runtime/provider evidence, documentation authority, regressions, acceptance, or deciding what evidence deserves permanence. Manage the transition from uncertainty to justified confidence and preserve durable guarantees without turning every probe into infrastructure.\"\n---\n\n# Evidence Stewardship\n\n## Purpose\n\nEvidence Stewardship owns **proof**:\n\n> **What justifies confidence, at what claim level, and what evidence deserves to survive?**\n\nIt is not a mandatory phase and does not own product meaning.\n\n## Ownership boundaries\n\n- Development OS owns evidence appetite, stage/liveness, and authority posture.\n- Founder-to-Feature owns acceptance meaning.\n- Specialist Reasoning owns perspective.\n- Evidence Stewardship owns proof selection, evidence interpretation, uncertainty, and permanence.\n- Lean owns verification cadence and execution mechanics.\n\n## Evidence is not authority\n\nTests, docs, screenshots, logs, generated graphs, comments, and history are evidence. They do not automatically outrank current owned product truth.\n\nWhen evidence conflicts, identify what guarantee each artifact claims to protect and which source actually has authority.\n\n> **Preserve guarantees, not historical artifacts.**\n\n## From uncertainty to justified confidence\n\nEvidence Stewardship is most valuable when evidence is missing, stale, contradictory, or poor.\n\nAsk:\n\n1. What claim are we trying to establish?\n2. What is currently observed, derived, inferred, contradicted, or unknown?\n3. What is the cheapest reliable evidence that could change the decision?\n4. At what real boundary does the claim exist?\n5. Does the resulting proof deserve permanence?\n\nMatch the **level of proof to the level of the claim**.\n\nDo not fill evidence gaps with plausible model inference.\n\n## Battle-test hypotheses and durable findings\n\nBattle testing and broad observation deliberately generate possible weaknesses. They are not durable truth merely because they sound plausible.\n\n> **Battle testing generates hypotheses; persistence requires evidence.**\n\nFor each material incidental finding, distinguish:\n\n- **supported obligation** — enough evidence exists to state a concrete unresolved problem;\n- **investigation** — the anomaly is material but correctness, intent, or root cause is unresolved;\n- **temporary hypothesis** — not yet strong enough to deserve durable routing.\n\nBefore creating durable work, check whether an equivalent unresolved item already owns the obligation and whether several observations share one root cause. Preserve every warranted distinct obligation; do not cap issue count arbitrarily.\n\nThe durable work system owns unresolved obligation, not final truth. When work resolves, reconcile accepted durable meaning into its natural living owner and close/retire the temporary obligation artifact.\n\nRespect information sensitivity and destination visibility. Evidence does not become safer to publish merely because an issue tracker is convenient.\n\n## Development evidence is temporary by default\n\nUse temporary proof freely when it is the cheapest way to learn:\n\n- reproductions;\n- diagnostic tests;\n- fixtures/scripts;\n- logs/instrumentation;\n- screenshots/browser checks;\n- benchmarks;\n- source/topology comparisons.\n\nDelete it when the question is answered unless it protects a durable guarantee worth carrying.\n\n## Durable guarantees deserve durable protection\n\nExamples include:\n\n- authorization/privacy/security boundaries;\n- destructive-data safety;\n- identity/ownership invariants;\n- serialization/file-format compatibility;\n- idempotency/concurrency;\n- billing/entitlement correctness;\n- migration guarantees;\n- published APIs/protocols.\n\nProtect the stable behavior at the cheapest reliable boundary. Do not freeze incidental implementation shape.\n\n## Evidence classes\n\nUse whichever class resolves the uncertainty; the taxonomy is descriptive, not workflow:\n\n- **Probe** — temporary evidence created to learn.\n- **Contract / guardrail** — durable automated protection for a stable guarantee.\n- **Acceptance evidence** — proof at the real user/provider/product boundary.\n\nMocks can establish internal logic. They cannot prove external reality.\n\n## Degraded evidence and documentation\n\nWhen a repository has no good evidence, create the smallest temporary probe needed to distinguish plausible stories.\n\nWhen documentation is absent, do not manufacture documentation merely to create evidence.\n\nWhen documentation conflicts:\n\n- identify explicit ownership/currentness;\n- compare against source/runtime/provider state;\n- determine whether code is a regression, docs are stale, or authority is genuinely unresolved;\n- keep unresolved claims unknown until stronger evidence or human intent decides them.\n\nFor many documents, build only a temporary authority map needed for the active objective. Do not maintain everything by default.\n\nDocumentation earns permanence under the same rule as tests: it must carry durable meaning that cannot be cheaply/reliably derived elsewhere.\n\n## Proof follows uncertainty\n\nChoose proof that targets the real remaining uncertainty:\n\n- source/static/type/schema checks;\n- deterministic tests;\n- runtime/provider reads;\n- browser/device journeys;\n- artifact inspection;\n- realistic-scale performance;\n- operational telemetry;\n- human physical/taste acceptance where inherently necessary.\n\nDo not silently escalate proof merely because another check exists.\n\n## Permanence judgment\n\nBefore adding or retaining permanent evidence, ask:\n\n1. What durable guarantee and meaningful harm does this protect?\n2. What is the cheapest stable mechanism/boundary that can prove or enforce it?\n3. Is that guarantee already protected elsewhere?\n\nIf the answers are weak, keep evidence temporary.\n\n## Use the Founder-to-Feature crystal\n\nWhen a Crystallized referent exists, derive proof from **acceptance meaning**, not from incidental code structure.\n\nA crystal is working semantic context; it does not need a permanent crystal artifact.\n\n## Bugs and regressions\n\nFor a failure:\n\n- preserved accepted behavior failed → likely regression;\n- behavior intentionally changed/retired → old evidence may be obsolete;\n- test only freezes implementation → reconsider permanence;\n- intended meaning unclear → return to Founder-to-Feature;\n- harness/environment broken → repair/isolate proof infrastructure.\n\nDo not bend accepted behavior around an obsolete test just to make CI green.\n\n## Consolidation and deletion\n\nDelete or consolidate:\n\n- duplicate proof;\n- stale source-text/import assertions without compatibility reason;\n- snapshots freezing incidental structure;\n- obsolete behavior;\n- one-time migration probes after stronger protection exists;\n- redundant regressions subsumed by guardrails;\n- abandoned fixtures/helpers/docs that no longer own unique durable meaning.\n\nEvidence is institutional memory only when it protects something worth remembering.\n\n## Performance and external reality\n\nMeasure performance at realistic scale and boundary when it matters. Prove provider/auth/deployment behavior against the real provider when practical.\n\nDo not claim production or external truth from local mocks.\n\n## Evidence debt\n\nEvidence debt exists when important accepted guarantees have no reliable proof, proof is so brittle it blocks safe change, or competing evidence prevents trustworthy decisions.\n\nPrioritize evidence debt by consequence, not coverage percentage.\n\n## Completion\n\nEvidence work is complete when the objective-level claim has enough justified proof, material contradictions/unknowns are explicit, and temporary evidence has been removed or deliberately promoted.\n\nGreen CI alone is not product acceptance.\n\n## Communication style\n\nKeep Evidence Stewardship mostly invisible. Surface only material uncertainty, proof boundaries, contradictions, or permanence decisions.\n\n## Anti-patterns\n\nDo not:\n\n- add tests for coverage theater;\n- require TDD universally;\n- add a permanent regression for every bug;\n- treat tests or docs as unquestionable authority;\n- claim external reality from mocks;\n- keep probes forever;\n- create testing/evidence ledgers by default;\n- automate unstable taste judgments merely for objectivity;\n- generate documentation because documentation is missing.\n\n## Governing maxim\n\n> **Move from uncertainty to justified confidence at the real claim boundary, then keep only the evidence worth carrying forward.**\n\n"
}