BOHICA-LABS / BOHICA-LABS/vsdd-factory

policy(spec-steward): POL-003 VP source_bc frontmatter shape asymmetry — pinned vs unpinned makes version-sync machine-uncheckable

Open
#453 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
Rust
Stars
2
Forks
1
Avg merge
6h 43m
Merged PRs (30d)
29

Description

## Context

- Plugin: vsdd-factory `1.0.0-rc.21`
- Project: Go multipath tmux relay (switchboard), Phase 5 Adversarial Refinement
- Origin: Pass 6 Adv-B obs-3 `[process-gap]` adjudication → deferred as drift item `DRIFT-POL003-VP-FRONTMATTER-VERSION-PIN` per the Cycle-Closing Checklist (S-7.02); filing upstream so the refinement lands in POL-003's own backlog

## Symptom

VP frontmatter `source_bc:` has **two shapes in circulation**, and the plugin's own template and POL-003 enforcement practice each produce a different one:

1. **Unpinned** (template-canonical): `source_bc: BC-2.08.001`
— this is what `templates/L4-verification-property-template.md` line 12 prescribes: `source_bc: BC-S.SS.NNN`
2. **Pinned** (POL-003-fix-burst-emergent): `source_bc: BC-2.07.001 v1.12`
— produced when adversary findings cite POL-003 and spec-steward "syncs the pin" (e.g. our VP-048 v1.7/v1.8 changelog rows both describe POL-003 pin syncs)

Empirical distribution in our project after ~8 adversarial passes:

| Shape | Count | Files |
|---|---|---|
| Unpinned | 73 / 76 | everything else |
| Pinned | 3 / 76 | VP-043, VP-048, VP-062 |

The three pinned VPs are exactly the ones that were touched by POL-003 findings. Each POL-003 fix-burst converts another VP from template-canonical shape to pinned shape — the drift is monotonic and enforcement-driven.

## Why it matters

POL-003's promise is machine-checkable BC↔downstream version sync. A tool auditing "does this downstream artifact cite the current BC version?" cannot mechanically answer for a VP whose `source_bc:` omits the version — there is nothing to compare. With mixed shapes:

- A grep-based POL-003 lint over `source_bc:` either false-negatives on 73 unpinned VPs (nothing to check) or must special-case two grammars.
- Adversary lenses treat "stale pin" as a MED finding on pinned VPs, while identically-stale unpinned VPs are invisible — same underlying staleness, different detectability, purely by shape accident.
- The substance IS anchored via Story Trace tables in the VP body, so there is no correctness defect today — but the frontmatter shape asymmetry means the machine-checkable layer and the human-checkable layer disagree about where version truth lives.

## Interaction with #429 (cascade non-termination)

These must be decided together. If the resolution here is "pin all 76 VPs," the POL-003 cascade surface grows ~25×: every governance-only BC bump would demand 76 potential frontmatter syncs, which is exactly the non-terminating cascade class #429 describes. If #429's resolution is "governance-only bumps don't cascade," then pinned shape becomes affordable. If instead the resolution is "unpin everywhere," #429's cascade pressure drops for VPs entirely.

## Proposed fix

Pick ONE canonical shape, encode it in the template, and ship a machine check — either direction closes the gap:

**Option A — pinned everywhere:** `source_bc: BC-N.NN.NNN v` required on all VPs. Update `L4-verification-property-template.md` line 12. Ship a lint (adversary Lens-3 pre-check or CI script) that parses the pin and compares against the cited BC's current frontmatter `version:`. Requires #429's governance-only carve-out first, or the cascade is non-terminating.

**Option B — unpinned everywhere:** strip pins from frontmatter (frontmatter names the BC identity only); version anchoring lives exclusively in body Story Trace / Source Contract tables, and the POL-003 machine check targets those tables instead. The 3 pinned VPs get normalized back to template shape.

Either way, the decision should land **before or with** the `source_bcs: [...]` schema rename the template's line-12 comment already foreshadows — otherwise the shape question multiplies across the `bcs:` list field too (pinned list entries vs unpinned list entries).

## Refs

- #429 — POL-003 bidirectional-pin cascade non-termination (sibling; joint resolution needed)
- #396 — citation-corpus sweep on BC bump (adjacent: body-prose pins; this issue is the frontmatter layer)
- `templates/L4-verification-property-template.md` line 12 (`source_bc: BC-S.SS.NNN` + `bcs:` list schema note)

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.