docs: restore 61 promoted potential records stranded on an unmerged branch

[drmoisan]

docs: restore 61 promoted potential records stranded on an unmerged branch

Summary

• Restores 61 promoted potential-bug records that exist only on origin/epic/quickfiler-per-file-coverage-integration, a branch that is not an ancestor of main. Deleting that branch would have destroyed them.
• These records are the only complete requirements source for the 48-item QuickFiler bug corpus. The corresponding GitHub issue bodies are stubs, with several sections reading (not provided in potential file).
• Strictly additive: 61 files added, 0 modified, 0 deleted, all under docs/features/potential/promoted/. The 41 records already on main are untouched.
• Unblocks epic preparation for the QuickFiler corpus. Without these records, per-feature specs would be written against terse issue prose rather than grounded requirements.

Why

An epic-planning pass over the QuickFiler bug corpus found that its requirements documents were missing from main. Verification confirmed the gap and showed it is larger than first reported:

potential docs on epic branch : 102
potential docs on main : 61
present on branch, absent on main : 61
branch merged into main? : NOT merged

The records are substantially richer than the issues they back. For issue #475:

Source	Size	Content
Potential record	5,749 bytes	Summary, Environment, Suspected Cause, Production Call Sites (verified 2026-08-07), Steps to Reproduce, Expected Behavior, Actual Behavior, Impact / Severity, Suggested Remediation
GitHub issue body	2,452 bytes	Summary, with later sections reading (not provided in potential file)

Two distinct risks are closed. First, data loss: 61 documents of analysis sat on an unmerged branch, and routine branch cleanup would have taken them. Second, planning quality: any specification derived from the issue bodies alone would lack the verified call sites and remediation guidance that make these defects actionable.

What Changed

Path	Change
docs/features/potential/promoted/*.md	61 files added (5,592 lines)

Nothing else. No code, configuration, test, workflow, or pushed-down .claude path is touched.

Verification

Completed

Check	Result
Restore scope	git status reports exactly 61 entries, all A (added)
Path confinement	0 paths outside docs/features/potential/promoted/
Overwrite safety	The 41 records present on both main and the source branch were excluded from the restore set, so no existing record is modified
Push-down safety	0 restored paths under .claude/ or config/ — none is a push-down destination, so the next sync cannot revert this
Diff shape	61 files changed, 5592 insertions(+), 0 deletions
Source provenance	Every file restored from origin/epic/quickfiler-per-file-coverage-integration by exact path, computed as the comm -23 set difference against main

Not applicable

The C# toolchain (CSharpier, analyzers, nullable, MSTest) is not exercised: the diff is Markdown only, with no *.cs, *.csproj, *.props, *.targets, *.config, or workflow file. CI runs regardless and gates the merge.

Backward Compatibility / Migration Notes

None. Adding Markdown records changes no public surface, build input, or runtime behavior. The source branch is left intact; this PR copies from it rather than merging it, so no unrelated change on that branch is pulled in.

Risks and Mitigations

Risk	Assessment	Mitigation
A restored record contains stale line references	Confirmed for at least six records — 286.md is off by +17 lines, 462.md by +46; 474.md asserts an interface premise that is already false because IQfcFormController.cs:13 inherits IFilerFormController; 482.md misattributes registries; 498.md places two files in the wrong project; 440.md claims a shared row type that does not exist	Recorded as known-stale in the epic manifest. Each preparation child re-derives its own line numbers rather than trusting the record. Restoring a record with a drifted reference is still strictly better than having no record
Restoring a promoted record for an already-closed issue	Possible; the set was computed by path difference, not by issue state	Harmless — these are historical provenance artifacts, and their value is the analysis, not the issue's open/closed state
Divergence from the source branch later	The branch remains unmerged and may continue to move	This PR is a point-in-time restore of records that were otherwise unreachable from main; it does not attempt to track the branch

Rollback is git revert of the single commit, with no build or data implications.

Review Guide

61 files, one commit, additive only. Reviewing every record is not a good use of time. Suggested approach:

1. Confirm the shape: git diff --shortstat main..HEAD should report 61 files changed, 5592 insertions(+) with zero deletions. A deletion would mean the restore set was computed wrongly.
2. Confirm confinement: every path begins docs/features/potential/promoted/.
3. Spot-read one record — 2026-08-07-breadcrumb-capturecurrentortests-silently-degrades-in-production.md (backing Bug: breadcrumb-capturecurrentortests-silently-degrades-in-production #475) — against the issue body, to confirm the records really are the richer source.

Follow-ups

• The six drifted line references above are recorded in the epic manifest rather than fixed here; correcting them belongs with the child that touches each file, which will re-derive the line numbers anyway.
• Worth deciding the fate of origin/epic/quickfiler-per-file-coverage-integration. With these records on main it no longer holds unique requirements content, but it should be inspected for anything else unique before deletion.
• The wider gap is process rather than content: promoted records were written on a feature branch and never reached main. A check that a promoted record accompanies its issue onto the default branch would prevent a recurrence.

GitHub Auto-close

• None

This restores documentation for issues that remain open; it fixes none of them, so no closing keyword applies.