Repository navigation
🐛🧑💻 - Pre branch SDD assembly rejects an undefined requirement after the bounded repair on a resolved UI feature #833
Description
Is there an existing issue for this?
- I have searched the existing issues.
Related closed #695 fixed independent case-budget/traceability generation through trusted assembly. This observation is on the later published v3 and fails assembly because a case names an undefined requirement. Please consolidate/reopen if the root cause is shared; do not relax the strict validation.
Which actions are affected?
Issue
Which platforms are affected?
Linux
Description
A resolved Domus UI feature cannot publish its pre-branch companion because SDD generation and its one bounded repair both leave requirement mappings invalid. Assembly detects one case reference not defined by the requirement table. No candidate text, identifiers or editable draft are retained, so a maintainer cannot directly correct the generated row.
Expected: produce a closed requirement/case inventory satisfying the unchanged assembly contract, preserve all resolved scope and answers, or provide safe actionable row/count provenance and a supported recovery. Undefined references must remain rejected; prior specifications and branch ownership must be preserved.
Actual: validation.invalid-input, reason requirement-mapping, phase assembly, draftAttempts=2, section14, expected0/observed1. Publication stops, retryableNo, with no new SDD or branch. This is a generated-draft failure, not an application test failure or a queue delay.
Reproducing the issue
- Consumer: ✨🧑💻 - Deliver the household entry interface for native and standalone deployments domus#8, household entry UI companion under existing application-experience; selected base 0012a172492515e282be09c37921f4014a451e64.
- The maintainer supplied owner-confirmed membership actions and a bounded per-tab recovery journal in comment 6547492565. Round2 asked whether real frontend coverage/CI must be established by the increment.
- The maintainer confirmed that current evidence is architecture-policy tooling only, and requires actual authored frontend execution, all four supported metrics at100, Storybook/Playwright and preserved CI gates in comment ✨🧑💻 - Deliver the household entry interface for native and standalone deployments domus#8 (comment).
- Inspect run https://github.com/vypdev/domus/actions/runs/41230775365, job https://github.com/vypdev/domus/actions/runs/41230775365/job/124624351974.
- Initial execution admitted 2026-10-31T18:44:41.8996212Z and completed18:44:58.7394213Z; drafting admitted18:44:58.7795791Z/completed18:46:25.3473200Z; bounded repair admitted18:46:25.3753416Z/completed18:47:28.5739386Z.
- At18:47:28.5761150Z the gate reports the requirement-mapping failure. The status card ✨🧑💻 - Deliver the household entry interface for native and standalone deployments domus#8 (comment) records the safe assembly facts; reply6547649466 repeats the same reference.
This is an exact observed run reproduction. The rejected candidate is unavailable, so no unknown identifier or deterministic model failure rate is invented. No manual rerun of unchanged input was requested.
copilot Version
Reusable issue-comment runtime and Action resolve to 3e7ceea; codex-cli0.166.0 on Linux. The resolved source SHA is authoritative.
Relevant Log Output
2026-10-31T18:43:51.5698688Z Download action repository 'vypdev/copilot@3e7ceea08e6131360e026937d1c0cc1b120472e0' (SHA:3e7ceea08e6131360e026937d1c0cc1b120472e0)
2026-10-31T18:47:28.5761150Z Pre-branch SDD gate failed: The SDD draft still violates its requirement-mapping format contract after one bounded repair.
Error code: validation.invalid-input
Reference: e8ab5f73-2e3b-4845-bd37-498bb5c15479
Safe card facts: reason=requirement-mapping; phase=assembly; draftAttempts=2; section=14; expected=0; observed=1; a case refers to an undefined requirement. Candidate text/IDs/paths are withheld and no downloadable candidate is retained.
Additional context and comments
All product decisions for the two clarification rounds are answered. Existing household-identity/platform-foundation ownership, the unmerged foundation dependency, Clean Architecture, 100% authored frontend coverage and complete merge review remain required. No UI implementation begins before the Action publishes/verifies the branch and its dependency.
We will refine the same issue input with a closed requirement-ID/case seed, preserving all existing behavior and answers, then use the normal edited-comment workflow. That is a substantive input clarification, not a blind rerun or bypass. Its outcome is not yet established. Copilot source, installed resources, models, bounds and gates remain unchanged.
Useful regression controls include a resolved small/medium companion whose case names an undefined requirement after first draft and repair, multiple requirement edges, retained prior answers, safe row attribution, and exact branch/publication non-effects on terminal failure. #695's derived budget/reverse-mapping assembly should not be assumed to prevent undefined generated references. No credentials, owner HA data or private browser state are included.
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
Activity
[-]Pre-branch SDD assembly rejects an undefined requirement after the bounded repair on a resolved UI feature[/-][+]🐛 - Pre branch SDD assembly rejects an undefined requirement after the bounded repair on a resolved UI feature[/+]vypbot commentedon Oct 31, 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.efraespada commentedon Oct 31, 2026
Follow-up observations and consumer input correction; these do not establish a shared root cause with the original undefined-requirement failure.
The closed requirement/case seed was initially appended after the one-line
SDD Q1:answer. Source inspection confirmed that parseSddAnswer deliberately consumes only one matching line, bounded to 3..3000 characters. Likewise, my first round-3 technical answer used explanatory continuation lines, which the documented parser did not retain. That was a consumer formatting mistake. The resultingexceeded three roundsfailure (run 41233424272, job 124632137946, reference cc2eedd3-aa26-45be-8aa1-ad7aca6b2443) is not evidence of another Copilot defect. I corrected the two answers to complete single lines (2630 and 2936 characters) and moved the entire eight-requirement/48-case inventory and all prior design decisions into the issue description. No parser, round bound or question card was modified.Two normal edited-comment executions of the consolidated input subsequently reached a different generated-draft validation failure:
The SDD draft still violates its repository-path format contract after one bounded repair.Error validation.invalid-input; reference086d698f-16a4-43e4-bd40-0b0890fec325.Both used the same pinned v3 runtime 3e7ceea and codex-cli0.166.0. No SDD or linked branch was published. Safe output says cited repository paths could not be verified at the immutable base, and asks for existing-path correction or explicit new-file declarations. Candidate content and exact rejected paths remain unavailable; I cannot identify which row failed or claim deterministic model behavior. The retained question card still identified the older base0012a172492515e282be09c37921f4014a451e64, but it was from the previous clarification round, so it alone does not prove either later attempt's actual workspace base. Do not treat the unverified base explanation as a diagnosed root cause.
The foundation PR #7 merged into develop at302e440362359f530bee7c09445792e13a59300d on2026-10-31T19:27:00Z, preserving source72e3e87dc7da241327384424a7e179bea2f83151. Current develop now verifiably contains the cited backend/API documents. I have substantively updated the same issue to state that dependency, replace brace-style shorthand with exact contract paths, and explicitly list29 proposed new files as create rather than existing evidence. All48 cases, decisions, bounds and gates remain inside the unchanged30000-character issue prompt bound (current body29728 characters). The new normal issue-edit execution is https://github.com/vypdev/domus/actions/runs/41234858970; it is still running, so no recovery/publication success is claimed. No unchanged-input manual retry, branch override or Copilot edit is used.
Please keep these safe diagnostics with the original report, splitting the repository-path observation if its root cause differs. Fail-closed validation is correct; an actionable exact non-content row/count category and a valid bounded repair remain the desired experience. No owner HA data, credentials, private Ingress URLs or rejected candidate text is included.
efraespada commentedon Nov 1, 2026
Further released-SDK occurrence in Domus recurrence issue #17 after supported companion recovery: https://github.com/vypdev/domus/actions/runs/41338750425 . Safe card vypdev/domus#17 (comment) now records reason=requirement-mapping, phase=assembly, draftAttempts=2, section 4, data row 1, identifier-list invalid/repeated syntax, expected 0 / observed 15. Reference 01309470-f096-42be-bdf1-8dc0670ae9f6. Actual candidate text/IDs are unavailable; the evidence does not establish which generated identifiers were malformed or whether they were concatenated. Strict rejection is correct.
Same immutable SDK 3e7ceea and Codex CLI 0.166.0. This follows the distinct 18000-character update-size failure reported in #763 and the selected-base/default-checkout mismatch in #836; do not conflate their causes. No specification or branch was published by either failed preparation.
Substantive recovery input has now been prepared outside the checkout: one reviewed companion with 8 single requirement-ID rows and 52 explicit distinct boundary cases. All 7 unchanged original policy modules were independently Git-blob verified. Original trusted assembly plus validateSddMarkdown and validateSddDraftConsistency pass against immutable 63d1159 and all 15 actual owning documents. Raw 36855 characters; rendered 39580; rendered SHA256 5df71eae4e5d266d98eb88ed1fa1d98075c8398f26c395b87da1dcc9ea61312e. The original owner and all 37 cases/budgets remain unchanged. No original policy, SDK resource, validator, configuration, credential, bound or remote branch was modified.
The complete reviewed raw candidate will be supplied as explicit normal issue input, retaining the two original derived-table slots and exact validated definitions. This validates only input format/consistency; Action catalog/publication/branch readiness and actual runtime acceptance remain unproven. Please retain this distinct section 4/identifier-list occurrence and its bounded repair evidence. It is not a claimed deterministic provider-failure rate or proof that the original validator is defective.
efraespada commentedon Nov 1, 2026
The same released-SDK requirement-identifier assembly failure is now observed on the separate resolved household administration issue #16: https://github.com/vypdev/domus/actions/runs/41340042726 . Safe card vypdev/domus#16 (comment) ; reply 6562563817. Reference 3dbdb1e8-12e5-4dfc-848e-562a41a4789a; reason=requirement-mapping, phase=assembly, attempts 2, section 4, normalized data row 1, expected 0 / observed 13, invalid/repeated identifier-list syntax. Exact malformed IDs/candidate text remain unavailable; no specification or managed branch was published. The owner had confirmed name/alias and self/current-admin alias editing, and the maintainer supplied concrete schema/restore/journal contracts.
Do not infer a malformed first requirement from the normalized row field alone: unchanged original uniqueIdentifiers checks the collected requirement-ID list through the strict identifier parser, so the observed 13 is an aggregate list count. Hidden candidate text is still needed to identify the offending values; no such values are invented here.
The consumer is supplying a closed eight-ID HADM-01..HADM-08 requirement seed, each as an actual separate definition, a reciprocal risk inventory basis, approved same-owner companion placement and a complete retained migration answer. This is substantive normal input clarification, not a blind failed-job rerun. The original companion/owner cases, full UI/authority/restore behavior, per-module/global 100% supported coverage and publication checks remain required. No Copilot source/resource/configuration/credential/gate change or contributor-created remote branch has been performed. Please preserve both the recurrence observed 15 and administration observed 13 occurrences without claiming the validator itself is defective or that the provider always fails.
efraespada commentedon Nov 2, 2026
The same defect now blocks this repository's #853, a prerequisite for #830 / PR #852 and extension H3 #704 / PR #837. Reuse #833; do not create a duplicate or weaken publication validation.
Observed current-source evidence (develop 9d39157):
Implement a narrow correction to this existing repair contract: forward only freshly normalized bounded host diagnostics to its existing sole regeneration; emit safe ordinal/count provenance for undefined/uncovered requirement links and derived-slot failures where deterministically available. Never send rejected Markdown, identifiers, paths, arbitrary error messages or secrets, infer missing requirements, alter definitions, auto-accept a result, add generations, raise limits or change the selected owner/branch lifecycle. Provider/workspace/catalog errors retain their existing identity and no content repair. Revalidate every corrected candidate through all existing checks before any publication.
Use the existing issue-start-and-sdd-readiness owner and pre-branch SDD/recovery docs. Preserve all existing product/quality gates. Add actual RED/green regressions covering assembly and writer-validation coordinates, native adapter round-trip, malformed/extra diagnostic data, retained exact request/owner/schema, unchanged one-repair budget, provider/cancellation identity, and failed-publication non-effects. Reserve at least20 distinct risk cases across pure coordinate facts (8), repair orchestration/security (8), and native publication/compatibility (4). Correct-base Codecov must show every modified coverable line hit with zero partials, complete review must have no active findings, and a separate final-SHA human protected-path decision remains mandatory if requested. No release, tag, deploy, model or browser permission change.
8 remaining items
vypbot commentedon Nov 2, 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)
efraespada commentedon Nov 2, 2026
Additional occurrence on the unchanged released consumer runtime (not a claim about a newer upstream fix): Domus issue #21 failed requirement mapping during companion assembly.
requirement-mapping, phaseassembly, draftAttempts2, section14, expected0, observed1undefined requirement reference; referencee9c4f671-c014-4072-8e85-5a5120dbb90b. The rejected candidate and exact offending identifier are not exposed; no internal prompt or hidden identifier is inferred.3e7ceea08e6131360e026937d1c0cc1b120472e0. Existing registered administration owner and all 72 original case rows were preserved. No Copilot code, limits, workflows or validation policy was changed.Supported recovery succeeded. After supplying a complete, closed eight-requirement/eight-refinement companion proposal in the issue body (not only a technical comment), the Action published
specs/household-administration-integration.mdand both catalogs at a9c4b9723c66868884476743940102ada65d2db0, parent 4b71969d3b3f6df5f28d617ab0da4e86c9be5884, then marked the exact managed issue21 branchbranched. Gate: vypdev/domus#21 (comment) . Native published document is 40,267 UTF-8 bytes; it differs from the private proposal and is not represented as an identical copy. Original pinned SDK format and owner-consistency checks pass on the published document with consumer-owned factual hash/path corrections, with all seven original policy modules byte-verified. That local check is not a gate bypass or runtime acceptance. Implementation now proceeds; all original 72 product journeys remain required, separately from the eight integration refinements.efraespada commentedon Nov 2, 2026
New terminal requirement-mapping occurrence on Domus continuation25, independently distinguished from earlier size/circular-source observations. Run https://github.com/vypdev/domus/actions/runs/41466725960 , Copilot-Issue job125349518671, released3e7ceea08e6131360e026937d1c0cc1b120472e0. It logs at2026-11-02T15:00:34Z that the draft still violates requirement-mapping after one bounded repair; public diagnostic validation.invalid-input / phaseassembly / draft attempts2 / referencee34d3ce7-0abc-4e56-ba1b-4c776fc06b4b supplies no specific row facts. Updated failure card vypdev/domus#25 (comment) . No failed candidate is downloadable, so its exact malformed requirement table cannot be independently diagnosed.
At observation, the same issue also retains the phase=published gate vypdev/domus#25 (comment) pointing to171244421fcc6289180bdb94bf4e7bb52a990a1b, exact parent6d84d4815a8bbfe071979df6650d01e433dcc2db and existing Action-owned feature/25-complete-household-administration-apis-and-workspace-over-verified-schema9-profile-storage. Current API ref still equals1712444. The published companion contains8 linked HADW requirements and8 matched cases; its unchanged-original-SDK format/consistency check passes against19 registered owner documents with all7 original policy modules Git-byte-verified. That successful published text does not prove the separate unpublished candidate was valid. All72 original administration cases and8 HADI refinements remain required.
The later terminal invocation leaves state:blocked/state:awaiting-maintainer and removes branched despite retaining the published gate/ref. Please preserve both the opaque mapping failure and this visible lifecycle inconsistency for a regression: a queued/repeated issue event should reconcile existing exact publication and avoid stale diagnostic/readiness ambiguity. No assertion about hidden model working directory or internal causal ordering is made solely from the outer checkout. Domus will not edit Copilot, invent/force/delete refs, weaken bounds or claim full product acceptance. Existing published work is retained; no healthy run is canceled or restarted.
Recovery outcome after the observation above: one retry of the terminal failed job produced125382987505 in the same run41466725960 and succeeded. The failure card6579913449 now says publication was verified on the linked branch; gate6580203928 retains exact171244421fcc6289180bdb94bf4e7bb52a990a1b and parent6d84d4815a8bbfe071979df6650d01e433dcc2db. API inspection confirms branched/state:working, with blocked/awaiting-maintainer removed. The ref was independently fetched before normal source commits. No healthy run was canceled or restarted and no contributor ref was invented. This records supported recovery; it does not establish an upstream fix or reveal the unpublished malformed candidate. Implementation continues in DomusPR26, retaining all72owner cases and untouched Copilot.