🐛🧑‍💻 - bug generated companion SDD publishes colliding case IDs and inconsistent acceptance mappings #653

Is there an existing issue for this?

• I have searched the existing issues, including SDD budget, traceability, companion/case and nonexistent-path reports; no matching issue was found.

Which actions are affected?

Issue

Which platforms are affected?

Linux

Description

The pre-branch SDD flow successfully published a companion draft and marked the managed branch ready, but the generated document contains conflicting acceptance identifiers, inconsistent per-area test allocations, requirement/case mismatches and a nonexistent documentation path. The issue and clarification answers explicitly selected an existing capability owner and retained its primary baseline.

This is a semantic correctness problem in the generated specification, not a request to require Kotlin files under a JavaScript layout or to accept implementation without review. A Draft-Proposed label appropriately leaves security/operator readiness open, but should not permit contradictions within the published contract or silently reuse an existing primary SDD's case identity for another behavior.

Expected: reconcile case identity against every SDD registered to the owner; verify each budget area's count and the requirement↔case mapping; resolve cited repository paths against the selected immutable base. If consistency cannot be established, repair the draft or publish a specific non-ready diagnostic. Preserve distinct draft-publication and runtime-acceptance states.

Actual evidence at first published commit 66631040d29c7c80a51d2d260347471421555ae4:

1. The new companion defines identity-tenancy-access-C01 as valid external project signature/claims → accepted principal. The existing primary SDD already uses that exact ID for missing bearer → 401. Its C02–C26 inventory also exists. The new companion then uses shorthand C02–C18, making cross-document references ambiguous. The two C01 meanings are opposite authentication scenarios.
2. Section 14 allocates 4 cases to session lifecycle/local compatibility, but its inventory gives that area six cases, C07–C12. Browser/API/live integration is allocated 4, but receives only C17–C18, two cases. The overall total happens to remain 18; checking only the grand total misses both category errors.
3. Section 17 associates G-04 with C12, while the C12 definition carries G-05 only. It associates G-08 with C18, while C18 carries G-01/G-07 only. G-09 maps to a generic documentation check instead of a defined case. Thus requirements, case definitions and traceability are not mutually consistent.
4. Section 15 instructs updating docs/cloud-development-environment.md, which does not exist in the selected base or published commit. The existing companion is specs/cloud-development-environment.md, and the operator guide is docs/platform/development-environment.md. The issue answers requested reconciliation of those actual artifacts.

Reproducing the issue

1. Use a repository with specs/catalog.json, the canonical standard/template and an existing identity capability primary SDD with stable requirement/case IDs.
2. Create an admitted feature requesting a new companion under that same capability while explicitly preserving the primary baseline. Provide the actual module/layout paths and clarify that preparation is documentation only.
3. Start the issue through in-progress; answer the eight blocking SDD questions using the documented SDD Qn: form.
4. Let the Action generate and publish the companion. Inspect the first SDD commit and its branched label/status card, then compare the draft's case IDs, category allocations, requirements and cited paths with the owner baseline and immutable base.
5. Observe the four concrete defects above despite successful publication.

copilot Version

Consumer workflow uses vypdev/copilot@v3; the installation was last verified as 3.9.3, resolving to f7f68e699a7f7cea46e0da62388ec1a643908ae9. The consumer's portable catalog validator is pinned to that exact source. Please use the linked run's resolved Action revision as authoritative if the moving v3 tag advanced since that verification.

Relevant Log Output

The public SDD status card reports:

phase: published
issueNumber: 199
round: 1
capabilityId: identity-tenancy-access
path: specs/development-identity-session.md
baseSha: 0741ee22dfaca8034975a81a4d1fc767863d89d2
commitSha: 66631040d29c7c80a51d2d260347471421555ae4

The native issue includes branched. No publication error was reported; the problem is visible in the generated document itself.

Additional context and comments

• Consumer issue: https://github.com/vypdev/platform/issues/199.
• Blocking question/status card: https://github.com/vypdev/platform/issues/199#issuecomment-6318051273.
• All eight scoped clarification answers: https://github.com/vypdev/platform/issues/199#issuecomment-6318108590 (3,975 characters; below the known 4,000-character comment context bound).
• Generation/publication run: https://github.com/vypdev/platform/actions/runs/39614081926.
• Immutable generated companion: https://github.com/vypdev/platform/blob/66631040d29c7c80a51d2d260347471421555ae4/specs/development-identity-session.md.
• Existing owner baseline: https://github.com/vypdev/platform/blob/0741ee22dfaca8034975a81a4d1fc767863d89d2/specs/identity-tenancy-access.md.
• The consumer is being specialized on the exact Action-owned ref through normal contributor commits; it now uses separate DEV case IDs, explicit per-case traceability and real document paths. The generated first commit is preserved, not rewritten.
• Suggested regression fixture: primary and companion with the same owner; deliberately duplicate a case ID with a different meaning; make category allocations disagree while keeping the same grand total; introduce a one-sided requirement link and nonexistent path. Verify a controlled, actionable non-ready result or a corrected output rather than silently publishing the contradictory contract.
• No credentials, real-account identifiers, private logs or provider responses are included. No application behavior or provider setting changed during this preparation.