🐛 - SDD ownership analysis proposes registered path companion for an explicit existing update request #856

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

1. Use the immutable development base4b71969d3b3f6df5f28d617ab0da4e86c9be5884. It is the actual PR22 merge and its tree is byte-identical to reviewed ed7cd14190d750846833cf1bb822988b628560da.
2. Use existing catalog capability household-identity and existing registered path specs/household-administration.md.
3. Start feature issue21 through its installed form/labels. Its body explicitly asks to update that existing companion and preserve every existing case.
4. Observe run41449262449/job125290282037 fail before SDD/branch readiness with companion-path-registered. The issue status card correctly exposes that closed reason.
5. 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.