Repository navigation
🐛🧑💻 - SDD ownership analysis proposes registered path companion for an explicit existing update request #856
Description
Is there an existing issue for this?
- I searched the exact diagnostic and related reports. Closed 🐛🧑💻 - Pre branch SDD ownership analysis fails without an actionable issue diagnostic or clarification card #636 now supplies the expected safe status card in this run; this report concerns the generated ownership choice for an explicitly requested existing update, not missing diagnostics.
Which actions are affected?
Issue
Which platforms are affected?
Linux (native Action); macOS (independent original SDK control)
Description
Starting Domus administration continuation issue21 after its actual schema8 prerequisite merge fails during pre-branch ownership analysis with companion-path-registered, although the request explicitly asks to update an already registered companion under its existing catalog owner.
Observed run: https://github.com/vypdev/domus/actions/runs/41449262449
Failed main job:125290282037.
Admission job:125290103535 succeeded.
Error: provider.contract-invalid; reference59b5788d-cc32-4f1b-9e9a-559eaf890240.
The request body available before this run stated: “Update the existing specs/household-administration.md companion under household-identity without duplicating its inventory or changing household-identity/delivery owners.” It selected actual development base4b71969d3b3f6df5f28d617ab0da4e86c9be5884 and preserved all72 cases and eight HADM requirements.
At that base, specs/catalog.json already lists both specs/household-identity.md and specs/household-administration.md under capability household-identity. A registered companion is an existing update target, not a new companion-creation path.
The original semantic guard is correct to reject a companion at a registered path. The native diagnostic establishes that its generated action was companion with a registered path. The rejected model payload and full planner prompt are not exposed, so the exact model-selected path/owner and whether every request sentence reached that prompt are unknown. This report does not invent those facts.
Expected: existing-publication update intent should resolve to the existing owner/path with action=update, or ask a targeted clarification before proceeding. Preserve all ownership, immutable-base and publication guards.
Actual: ownership analysis terminates with a registered-path companion decision, no draft or ready branch, despite the explicit existing-update request. The safe status card tells the maintainer to clarify and rerun; no automatic retry is performed.
Reproducing the issue
- Use the immutable development base4b71969d3b3f6df5f28d617ab0da4e86c9be5884. It is the actual PR22 merge and its tree is byte-identical to reviewed ed7cd14190d750846833cf1bb822988b628560da.
- Use existing catalog capability household-identity and existing registered path specs/household-administration.md.
- Start feature issue21 through its installed form/labels. Its body explicitly asks to update that existing companion and preserve every existing case.
- Observe run41449262449/job125290282037 fail before SDD/branch readiness with companion-path-registered. The issue status card correctly exposes that closed reason.
- Compare the valid intended ownership tuple with the same tuple using action=companion against the unchanged original SDK. The former passes; the latter produces the observed diagnostic.
Original SDK contract control:
const requested = {
action: "update",
capabilityId: "household-identity",
path: "specs/household-administration.md",
reason: "Update the existing registered administration publication on the verified schema8 base while retaining all original scope.",
questions: [],
};
parseSddPlan(requested, catalogOwners); // accepted
parseSddPlan({...requested, action: "companion"}, catalogOwners);
// SddOwnershipFailure("companion-path-registered")The control loads the actual catalog from the immutable base and the original pinned source. All seven original policy module Git blob identities were checked before in-memory TypeScript loading. No SDK file, validator, catalog, bound or source was modified. This is a contract control of the intended route, not a replay of the hidden native response or a claim that this exact path was the rejected payload.
copilot Version
vypdev/copilot@v3 resolved to3e7ceea08e6131360e026937d1c0cc1b120472e0.
codex-cli0.166.0; planner codex/openai/gpt-6-luna.
Managed branches and pre-branch SDD are enabled. The repository's installed feature workflow/profile is unchanged.
Relevant Log Output
2026-11-02T13:00:46.522Z Download action repository vypdev/copilot@v3, SHA3e7ceea08e6131360e026937d1c0cc1b120472e0
2026-11-02T13:01:45.077Z Agent execution admitted, codex-cli0.166.0
2026-11-02T13:02:03.552Z Pre-branch SDD gate failed: SDD ownership analysis rejected (companion-path-registered).
Clarify the catalog owner/path in the same issue and rerun the original workflow. No automatic retry was attempted.
Error code: provider.contract-invalid
Reference:59b5788d-cc32-4f1b-9e9a-559eaf890240
Additional context and comments
The #636 diagnostic behavior now works: safe issue-visible category, maintainer recovery guidance and no premature readiness/branch publication. Do not regress or relax it. This newer report asks to investigate route classification and input delivery for an existing registered companion update; it does not claim a validator defect, provider prompt coverage or a missing status card.
Consumer recovery is underway in the same issue: its body now supplies literal action=update, capabilityId=household-identity and path=specs/household-administration.md, explains that “companion” describes the existing document, and requests a bounded additive update preserving all72 rows. Normal queued events are left running; no healthy job is cancelled/restarted and no contributor replacement branch is created. Recovery has not yet been verified.
The prior verified product checkpoint was already merged at the owner's request with all product CI green, 4,031 backend tests/100% supported coverage and no open Bugbot findings. Full product scope remains active in issues21/23; this ownership failure is distinct from previously reported progress capacity, partial human-context accounting and the codec false positive. No Copilot resources/code/configuration/credentials or gateway were changed.
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
Activity
[-]SDD ownership analysis proposes registered-path companion for an explicit existing-update request[/-][+]🐛 - SDD ownership analysis proposes registered path companion for an explicit existing update request[/+]vypbot commentedon Nov 2, 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 Nov 2, 2026
Follow-up after the same-issue explicit ownership tuple clarification: normal run41450002797/job125293257310 now accepts action=update, capabilityId=household-identity and path=specs/household-administration.md at selected base4b71969d3b3f6df5f28d617ab0da4e86c9be5884. It reaches a round1 maintainer question, rather than a registered-path companion rejection. This establishes route recovery, not SDD/branch publication or a general provider fix.
The new question asks for an owning file already present in that selected snapshot; that known source-view defect is appended to#836. A separate earlier run41449269130 exhausted response size after2 attempts and is appended to#763. The owned status card6577800753 is rewritten in place, so the original URL no longer necessarily displays the initial ownership error. Exact original observation and terminal logs remain retained.
The maintainer answered Q1 in vypdev/domus#21 (comment) with the immutable snapshot/archive/file URLs and Git blobf315a00d9efbb7da8a9ea44de8a9df2d088e100a/SHA256333791e5664212473dd8874be9751c00c8ee7644cf9f861f11a3876dd97321f3, preserving all72 cases and existing bounds. No hidden candidate, exact rejected model-selected path or full prompt coverage is inferred. No Copilot or workflow change was made; normal queued continuation remains authoritative.
efraespada commentedon Nov 2, 2026
Recovery outcome for the issue21 observations above: the Action has now published the new companion and catalogs at a9c4b9723c66868884476743940102ada65d2db0 on the exact managed feature/21-complete-the-verified-household-administration-workspace-after-the-profile-model-foundation branch, with reviewed parent4b71969d3b3f6df5f28d617ab0da4e86c9be5884. The native published gate and branched readiness were verified before implementation. The original registered owner and72 case rows remain byte-identical. This recovered through the supported new-companion route after providing a closed complete proposal in the issue body; it does not establish a correction to the earlier update-size, ownership-route or selected-snapshot defects. No Copilot code, policy, limits, workflow or credentials changed. The intervening assembly mapping diagnostic is recorded in #833. Product implementation/acceptance remains outstanding.
efraespada commentedon Nov 4, 2026
Additional observation on 2026-11-04: Domus #30 now publishes the same safe
companion-path-registereddiagnostic after its package ownership questions were answered. This case requests a genuinely new independent shared-presentation package, rather than the existing-companion update in the original report; no common hidden model payload or exact rejected owner/path is inferred.Evidence:
At the exact selected base, specs/catalog.json has 11 owners and contains neither shared-presentation-package nor specs/shared-presentation-package.md; that path is absent from its Git tree. Its existing application-experience owner remains registered and must be preserved. The visible intended plan is therefore a new/unregistered tuple. The rejected payload is not exposed; this report does not assert that the guard rejected the visible tuple or invent which registered path the model selected. The semantic guard is correct to reject an actual registered-path companion.
Expected: preserve the explicit new-package ownership tuple, or ask a focused question before selecting an incompatible route. Actual: classification stops again with a registered companion path, no draft or ready branch. The maintainer has supplied the literal new tuple in the same issue and continues through the normal native workflow; no duplicate SDK execution, compatibility shim, manual replacement branch or Copilot modification is being introduced. Actual consumer runtime/source-context differences from a fixed development revision are not yet established, so this is not labeled a regression in that revision.
17 remaining items
vypbot commentedon Nov 4, 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.