integrity.stub_marker_threshold and integrity.duplicate_threshold are dead config keys

[explosivebit]

integrity.stub_marker_threshold and integrity.duplicate_threshold are dead config keys

Summary. Both integrity keys in .forgeplan/config.yaml are parsed, defaulted, and validated — then never read by the detection paths they name. Changing either has no effect on forgeplan health output: on our workspace (393 artifacts) 12 complete artifacts stay flagged as active_stubs and 40 as possible_duplicates, all false positives.

Verified against v0.37.0 (= main = commit 1b4525d).

stub_marker_threshold never reaches the stub detector

Step	Location
Defined	crates/forgeplan-core/src/config/types.rs:94
Default (3)	config/types.rs:135 (default_stub_marker_threshold)
Validated >= 1	config/types.rs:157
Never consumed	—

check_stub_detailed (crates/forgeplan-core/src/validation/rules.rs:138) takes (body: &str, _fm: &Frontmatter) — no threshold parameter — and ends with a hardcoded gate: if count >= 3 at rules.rs:247. All call sites (crates/forgeplan-cli/src/commands/import_cmd.rs:178, crates/forgeplan-core/src/health/mod.rs:1393, rules.rs:134) pass only body + frontmatter.

A full-tree grep for stub_marker_threshold finds only config/types.rs itself (definition, default fn, validation, unit tests) plus a template comment in workspace/init.rs:64.

duplicate_threshold is not used for duplicate detection

• Defined crates/forgeplan-core/src/config/types.rs:86, defaulted :129, validated to [0.0, 1.0] at :151.
• The active scan instead compares against a hardcoded constant: find_duplicate_pairs(all, DUPLICATE_SIMILARITY_THRESHOLD) at crates/forgeplan-core/src/health/mod.rs:843, where DUPLICATE_SIMILARITY_THRESHOLD: f64 = 0.7 at crates/forgeplan-core/src/duplicate/mod.rs:16.
• Outside config/types.rs, the key appears only in workspace/init.rs:62 (template comment) and tests.

Consequence on a real workspace

12 complete, active artifacts (ADR-005, ADR-008, PRD-004, PRD-005, RFC-004, RFC-007, RFC-008, RFC-009, RFC-025, SPEC-004, SPEC-005, SPEC-006) are reported as active_stubs with Body appears to be unfilled template (3 markers found). The bodies are not templates: their prose uses RFC-6570 URI-template notation and IRI templates —

• GET /api/v1/bundles/{name}/{version}/download
• cphub:tenant:{tenantId}:alignments:set:{mappingSetId}

Each body carries 9–11 {param} tokens, tripping MANY_PLACEHOLDERS = 8 (rules.rs:193) for +2 on the +1 for "has any placeholder" — scoring exactly 3 against the hardcoded gate with zero template content. The {name} / {version} / {id} spelling is the correct REST parameter syntax.

40 possible_duplicates are distinct EVID artifacts whose titles share a generated template (Guardian gate review of RFC-0XX: PASS, RFC-03X architect-reviewer independent gate), clustering at Jaccard 0.714–0.778 — above the hardcoded 0.7. Each is a separate review of a separate RFC; none is a duplicate.

Raising either key in .forgeplan/config.yaml changes nothing (this was tried).

Ask

Either:

1. Thread the two keys through to check_stub_detailed / find_duplicate_pairs (both already accept or could accept a threshold), or
2. Narrow the brace-placeholder detector so RFC-6570 path parameters and IRI templates in prose are not counted as stub markers — and drop the keys if their values are meant to stay fixed.