CR-DD-016: Document capability-probe operator workflow discoverability

[coreytshaffer]

Authority boundary

Proposed documentation/help-text CR only. No runtime, routing, capability-resolution, freshness-policy, schema, test, or default-output-path changes are authorized by this PR.

This PR establishes the governed change request. It does not itself edit daily_driver_quickstart.md or tc probe --help — that implementation remains separately gated behind its own approval, per Status: Proposed / Implementation Authority: Not authorized in the document itself.

Scope

Exactly one new documentation file. 236 additions, zero deletions, zero other changed files.

• Added: docs/change/requests/CR-DD-016-capability-probe-operator-workflow-discoverability.md
• Not touched: any file under triage_core/, docs/daily_driver_quickstart.md, any schema, test, or config default. No relationship to docs: nominate governed knowledge substrate research venue #152, CR-AR-001: Risk-Tiered Deferred Human Review #153, or Document multi-worktree evidence-ledger census limitation #154 — this branch was cut from main at e842ed5 (after all three merged), independent history.

Background

A read-only investigation this session traced TriageCore's capability-observation lifecycle end to end — configuration (triagecore.toml's [capability] section), probe-record creation (tc probe), persistence, freshness/expiry (300s default), and consumption by tc run (capability_evidence.resolve_from_config → resolve_capability → routing). It used a real, naturally-occurring blocked evidence-window trial as motivating evidence, not as something manufactured for the purpose.

Finding: the block (capability_state: "configured", not "observed") is CR-DD-013's own designed, tested, intentional fail-closed behavior — not a defect. What's missing is the operator-facing half of CR-DD-013's own stated mitigation ("the configured-capability path and explicit release notes"): the primary onboarding document, daily_driver_quickstart.md, contains zero mention of tc probe, the [capability] section, or the two-step procedure required to move a declared capability from configured to observed.

Determination: an operator-workflow gap, with missing discoverability and documentation as the immediate defect — not an architectural gap (CR-DD-013 argued the fail-closed design explicitly and tested against exactly this), and not merely a documentation afterthought either, since the current path's brittleness (an undocumented manual two-step procedure, no CLI cross-reference, an undocumented short freshness window) makes discoverability part of the control surface.

What CR-DD-016 proposes

Two things, once separately authorized:

1. Documentation — add the missing tc probe → [capability].local_probe_record_path procedure to daily_driver_quickstart.md, including the 300-second freshness consequence, in language an operator hitting this block could act on without reading source.
2. CLI discoverability — update tc probe --help text to name [capability].local_probe_record_path explicitly as the required follow-up step for persisted --output to take effect.

Invariants this CR preserves (non-negotiable, stated explicitly in the document)

1. Configured never implies ObservedAvailable.
2. tc run never silently probes.
3. Stale or absent observations remain non-authoritative.
4. local_only continues to fail closed when required local capability is not observed.
5. Probe evidence remains explicit, inspectable, and time-bounded.

Deliberately out of scope

• No default --output path for tc probe. A predictable repo-relative default (e.g. .triagecore/local-backend-probe.json) reopens the exact class of problem already recorded in evidence-ledger-worktree-limitation-2026-08-07.md (PR Document multi-worktree evidence-ledger census limitation #154): which checkout owns the file across worktrees, whether a probe in one worktree could be read as authorizing routing in another, atomic replacement, concurrent probes, stale evidence at a predictable path. Deferred to a later, separately-scoped design question — not casually introduced here just because it looks convenient.
• No change to freshness_seconds or its semantics. The 300-second window is documented as-is. Whether the intended operational unit is probe-per-run, probe-per-session, or a bounded-refresh-window is recorded as an open design question, not answered — resolving it would reopen CR-DD-013 policy, which this CR does not do.
• No change to capability_evidence.py, resolve_from_config, resolve_capability, or choose_resilience_route.

Sequencing — A/B/C, explicitly non-inheriting

This is Track A of three. Tracks B (classifier terminal-fallback investigation) and C (privacy_level normalization/propagation investigation) are separate, independent, read-only investigations recorded in this document's "Related, Explicitly Out of Scope" section. Neither B nor C inherits any authority from A, and they are not to be combined with each other or with this CR even if both eventually warrant their own changes. For B specifically, the document preserves this exact boundary so the later investigation doesn't start from a contaminated premise:

The sunscreen run did not establish that the classifier reached the "refactor" fallback. The fallback was discovered during adjacent code tracing and remains an unconnected observation until a separate investigation establishes the actual execution path.

Numbering note

CR-DD-014 is historical fact (merged, explicit local route/model binding — unrelated to this CR). CR-DD-015 remains available, reserved for an anticipated separate comparative-lane track. This CR takes CR-DD-016, giving it an unambiguous provenance trail with no collision.

Verification

Check	Result
git diff --cached --stat	1 file changed, 191 insertions, 0 deletions
git diff --cached --check	no whitespace errors
git status --short	single A entry, no residue

Tests not run: no executable, schema, or test surface changed. No effect on the daily-use evidence window's protocol, eligibility rules, or duration requirement.

🤖 Generated with Claude Code

[netlify]

✅ Deploy Preview for poetic-quokka-0fd859 ready!

Name	Link
🔨 Latest commit	afbd470
🔍 Latest deploy log	https://app.netlify.com/projects/poetic-quokka-0fd859/deploys/6a7aa2ab45478700080fd46b
😎 Deploy Preview	https://deploy-preview-155--poetic-quokka-0fd859.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.