Repository navigation
Description
Is there an existing issue for this?
- I have searched the existing issues.
Which actions are affected?
Issue, Pull Request, Commits
Which platforms are affected?
macOS
Description
The SDD consistency validator rejects a legitimate technical designation in ordinary prose as a shorthand acceptance-case ID. In Domus PR #15, adding the sentence fragment Existing household DEL/C1 read compatibility remains separate from stronger new-setup input validation. to section 6 causes case-identity / case-shorthand, although C1 names the Unicode U+0080βU+009F controls and does not refer to a test case.
The candidate has all 48 original, fully qualified household-entry-interface-C01 through household-entry-interface-C48 case rows and unchanged reverse requirement mappings. Changing only that fragment to Existing household DEL and U+0080βU+009F read compatibility ... makes the same unchanged validator pass format, consistency and catalog validation. No acceptance row was removed, renamed, relaxed or counted as an executed test.
Expected: references to test cases must remain fully qualified, while ordinary technical identifiers in prose should not be classified as case references solely because they match C plus digits.
Actual: source.matchAll(/(?<![\w-])C\d+\b/gu) scans all visible prose and flags the Unicode designation after /. This can affect other legitimate identifiers such as connector/component designators. A consumer cannot describe the designation literally without rephrasing unrelated product documentation.
Reproducing the issue
- Use the valid SDD at https://github.com/vypdev/domus/blob/ca55cdb56779573a0dd45b47b9546b74b4ffcc74/specs/household-entry-interface.md with its existing owner documents and immutable inventory.
- Add
Existing household DEL/C1 read compatibility remains separate from stronger new-setup input validation.as ordinary section-6 prose. Leave every table and case ID unchanged. - Call
validateSddMarkdownandvalidateSddDraftConsistencywith the same owners/inventory/path. Format passes; consistency throws the diagnostic below. - Replace only
DEL/C1withDEL and U+0080βU+009F. All three format/consistency/catalog checks pass; original 48 literal case rows remain byte-identical.
Execution used Node 24.20.0 and the unmodified pinned SDK at 3e7ceea08e6131360e026937d1c0cc1b120472e0. Every diagnostic module was checked against its original Git blob before invocation. On 2026-11-01 the connected GitHub default-branch file read returned the exact same src/domain/sdd_draft_consistency.ts Git blob c1487eac45d12911052df9ce72ac1cdcb54e0b96 (SHA-256 04b6c1eebee7284270b8ad08107c2b2d01c4b3d059d5603a4eecab92616223fd), so this is not inferred from an obsolete different implementation. See
copilot/src/domain/sdd_draft_consistency.ts
Lines 174 to 175 in 3e7ceea
| const shorthand = [...source.matchAll(/(?<![\w-])C\d+\b/gu)]; | |
| if (shorthand.length) fail('case-identity', { detail: 'case-shorthand', section: 0, expected: 0, observed: shorthand.length }); |
copilot Version
Pinned SDK 3e7ceea; identical default-branch validator blob c1487eac45d12911052df9ce72ac1cdcb54e0b96 observed 2026-11-01.
Relevant Log Output
SddDraftFormatFailure [Error]: The SDD draft violates its case-identity consistency contract.
reason: 'case-identity'
diagnostic: {
reason: 'case-identity',
phase: 'validation',
facts: [{ detail: 'case-shorthand', section: 0, expected: 0, observed: 1 }]
}
Additional context and comments
Consumer: vypdev/domus#15, source base ca55cdb56779573a0dd45b47b9546b74b4ffcc74. Initial full candidate SHA-256: 58c8ffec266bcffafacf0a165d2a0c56088b5a52909891afee5f917068d48f08. Rephrased valid candidate SHA-256: fd19d9a13f85987c4462346b06b302a48499c874bf49075b623d1faeac44f3ec.
This was a local invocation of the actual unchanged validation functions, not a newly failed hosted Action run. Original failing input, raw diagnostic, passing receipt, source identities and commands are retained in the consumer's HTTP-adapter checkpoint. No Copilot source, configuration, credential, workflow or limit changed. We applied the consumer-only terminology workaround and continue implementation. Please fix and test this false positive upstream while preserving genuine shorthand/range/reference rejection and literal acceptance identities.
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsDone
Activity
[-]SDD consistency rejects the Unicode C1 designation in prose as a shorthand case ID[/-][+]π - SDD consistency rejects the Unicode C1 designation in prose as a shorthand case ID[/+]vypbot commentedon Nov 1, 2026
Hi! Iβm @vypbot, the Copilot assistant for this repository.
I can answer questions, explain the codebase, propose implementation and test plans, review issues and pull requests for potential bugs or security problems, and help authorized maintainers apply changes.
Try
/copilot helpto see the available commands, or mention @vypbot with your question.[-]π - SDD consistency rejects the Unicode C1 designation in prose as a shorthand case ID[/-][+]ππ§βπ» - SDD consistency rejects the Unicode C1 designation in prose as a shorthand case ID[/+]1 remaining item
vypbot commentedon Nov 3, 2026
Implementation plan
Acceptance: A regression test confirms that an SDD containing `DEL/C1` in ordinary prose passes consistency validation while genuine shorthand references and invalid ranges remain rejected, with literal case identities and reverse requirement mappings unchanged.
Need something else? Mention the bot with a question or use
/copilot help.vypbot commentedon Nov 3, 2026
Issue closed β historical progress
Current status: closed as completed.
The last estimate is retained below as history. Closure does not certify a new percentage, tests, or branch alignment.
Action required: none for this closed issue. If work continues, reopen the issue; a fresh assessment can update this same card.
Last assessment before closure (historical)
Merge pull request #874 from vypdev/bugfix/845-sdd-consistency-rejectβ¦
vypbot commentedon Nov 3, 2026
Issue closed: synchronization recommendation retired
No branch synchronization is required for this closed issue.
The previous recommendation is historical. Issue closure does not certify that the branches are synchronized.