🐛🧑‍💻 - SDK proposed capability catalogs have no truthful greenfield SDD bootstrap route without implementation evidence

Is there an existing issue for this?

I have searched the existing issues.
Searches covered catalog/bootstrap, proposed/evidence, entrypoints/tests and pre-branch/empty, including non-open-only searches. Related 🐛🧑‍💻 - bugfix pre branch SDD validator rejects Kotlin and other repository layoutstest conventions #595 concerns portable existing-file layouts; 🐛🧑‍💻 - Expose blocked pre branch SDD outcomes and safe recoverable draft diagnostics #714 concerns rejected-draft diagnostics; 🐛🧑‍💻 - Expose completed progress assessment validation failures instead of opaque agent.failed #774 concerns progress assessment diagnostics. None describes the truthful greenfield proposed-capability bootstrap gap below.

Which actions are affected?

Issue, Pull Request

Which platforms are affected?

macOS

Description

The supported SDK version-1 catalog recognizes status: proposed, but its validator requires nonempty entrypoints, code and tests arrays for every capability, including a prospective capability in a brand-new repository with no implementation.

This creates a greenfield SDD initialization problem: the pre-branch SDD flow requires a valid catalog/standard/template before a feature can start, while the proposed product SDDs cannot truthfully cite code/tests that do not exist yet. The documented standard requires honest evidence and forbids presenting specifications or planned acceptance cases as implemented source/tests.

Please investigate/reconcile the supported bootstrap contract, rather than blindly relaxing implementation/readiness validation. A supported route may require an explicit documented initialization lifecycle or status-aware evidence semantics. The reporter is not prescribing which policy is correct.

Observed consumer:

Documentation foundation: docs: establish Domus SDD foundation domus#3 and 📝🧑‍💻 - Establish the Domus SDD foundation product vision and architecture domus#2
Exact consumer head: ce2871b15508a1de53eaceca9bada001b31c25f2
Initial repository base: 8ee7e1a15e91c91b6204ca97e8808c3207dee008
The installed profile declares pre-branch SDD, but the baseline contained only README and the Copilot installation.
Eleven prospective SDDs cover 80 requirements and 281 planned cases. All remain Draft, with no product implementation, executed application tests or live acceptance claimed.
All eleven documents pass the unchanged original pinned validateSddMarkdown, validateSddDraftConsistency and canonical-heading checks. Original prerequisite standard/template structure also passes.
Every capability is uniquely registered as proposed; specification/documentation paths exist. Implementation fields are honestly empty.
The original validateCatalog returns exactly 33 errors, the three empty implementation-evidence fields for each of eleven entries; no other catalog validation error was returned.

Expected product behavior: a maintainer can initialize a new SDD-driven project with truthful prospective requirements and an explicit not-implemented/not-ready state, using a supported documented workflow. No synthetic source, empty wrapper tests, misclassified documentation paths, schema/status substitution or disabled gate should be necessary.

Actual behavior: the prerequisite catalog fails because implementation evidence is absent even for proposed, with no established truthful initialization route in the audited pre-branch guidance. A documentation issue provides an Action-owned review branch, but it does not by itself make the proposed product catalog pass or unblock a subsequent feature prerequisite.

Reproducing the issue

Run the immutable snapshot commands below. They produce 33 absent-evidence errors across eleven proposed capabilities.

Actual immutable consumer reproduction

Run in a new temporary directory; these commands clone snapshots and do not change any existing installation:

set -eu
copilot_repro_root="$(mktemp -d)"
cd "$copilot_repro_root"
git clone https://github.com/vypdev/domus.git domus-repro
git -C domus-repro checkout --detach ce2871b15508a1de53eaceca9bada001b31c25f2
git clone https://github.com/vypdev/copilot.git copilot-repro
git -C copilot-repro checkout --detach f5e5a4cf9a80248994469cd88ad55eecab5b95ca
node <<'NODE'
const path = require("node:path");
const validator = require("./copilot-repro/src/infrastructure/specification_catalog_validator.cjs");
const root = path.resolve("domus-repro");
const catalog = validator.readCatalog(root);
const errors = validator.validateCatalog(root, catalog);
console.log(JSON.stringify({
  capabilities: catalog.capabilities.length,
  statuses: [...new Set(catalog.capabilities.map(item => item.status))],
  errorCount: errors.length,
  errors
}, null, 2));
process.exitCode = errors.length ? 1 : 0;
NODE

The original CJS validator requires Node built-ins and its committed path-policy module; no consumer application installation or copied replacement validator is involved.

Expected observation for this snapshot: 11 capabilities, statuses ["proposed"], 33 errors for empty entrypoints/code/tests, exit code 1.

Source-level cause

Pinned source:
https://github.com/vypdev/copilot/blob/f5e5a4cf9a80248994469cd88ad55eecab5b95ca/src/infrastructure/specification_catalog_validator.cjs

Blob SHA: 7e32e203d5cf2e71f3a944e05c461a3e7f73a903
STATUS_LABELS explicitly includes proposed.
Every field in PATH_FIELDS must be an array.
For each field other than workflows, values.length === 0 unconditionally produces must not be empty; this condition does not inspect capability status.

At report time, default master still resolved to f5e5a4cf9a80248994469cd88ad55eecab5b95ca, and the current fetched validator blob remained the same. This is not a claim about an untested future version.

Evidence and boundaries

Consumer validation report: https://github.com/vypdev/domus/blob/ce2871b15508a1de53eaceca9bada001b31c25f2/docs/sdd-validation.md
Raw results and byte-verified upstream source provenance: https://github.com/vypdev/domus/blob/ce2871b15508a1de53eaceca9bada001b31c25f2/docs/evidence/sdd-validation.json
Proposed catalog: https://github.com/vypdev/domus/blob/ce2871b15508a1de53eaceca9bada001b31c25f2/specs/catalog.json
Adoption/readiness note: https://github.com/vypdev/domus/blob/ce2871b15508a1de53eaceca9bada001b31c25f2/docs/copilot-adoption.md
Pre-branch guidance: https://github.com/vypdev/copilot/blob/f5e5a4cf9a80248994469cd88ad55eecab5b95ca/docs/issues/pre-branch-sdds.mdx

The deterministic validator result was reproduced locally on macOS. Linux/Windows behavior is not independently claimed. No live feature-gate failure was intentionally triggered just to obtain a branch; the current issue uses the installed documentation workflow, and gate readiness remains explicitly unclaimed.

copilot Version

3.10.6; audited Action/source revision f5e5a4cf9a80248994469cd88ad55eecab5b95ca (vypdev/copilot@v3), with unchanged validator blob 7e32e203d5cf2e71f3a944e05c461a3e7f73a903.

Relevant Log Output

Original draft format and consistency: PASS, 11/11
Normative requirements: 80
Planned acceptance cases: 281
Original prerequisite standard/template structure: PASS
Original catalog result: BLOCKED, exactly 33 absent-evidence errors

capabilities[0].entrypoints must not be empty.
capabilities[0].code must not be empty.
capabilities[0].tests must not be empty.
...
capabilities[10].entrypoints must not be empty.
capabilities[10].code must not be empty.
capabilities[10].tests must not be empty.

The ellipsis only abbreviates this issue's display; the linked raw JSON contains every error and the reproduction prints the full list.

Additional context and comments

The owner explicitly requested detailed upstream reporting and no local modifications to Copilot. Neither Copilot implementation nor consumer-installed Copilot resources, statuses or checks were changed.

This is distinct from #774: Domus's Actions progress-assessment rejection has its own logs and does not show this catalog validator as its cause. Please keep those investigations separate.

Suggested acceptance for the owners' chosen solution:

Define and document a truthful greenfield initialization route, including interaction with pre-branch SDD and Action-owned branch admission.
A prospective document may remain explicitly not implemented and not Ready for implementation without fake implementation evidence.
Preserve strict existing-file containment, unique ownership, case/budget traceability and migration/status validation.
Preserve full evidence requirements for implemented/as-built capabilities; never convert planned acceptance rows into executed tests.
Define how proposed entries acquire real entrypoints/source/tests and transition toward implementation readiness, without breaking existing SDK catalogs or weakening unsupported-native-profile handling.
Add deterministic fixtures for an all-proposed empty-source repository, mixed proposed/implemented catalog, genuinely missing evidence, unsafe/nonexistent paths and a truthful transition to real evidence.
Expose an actionable CLI/Action next step for an unsupported greenfield state; a bare nonempty-array error is insufficient onboarding guidance.

Please triage this through the normal Copilot-owner workflow. This report does not start an implementation branch or authorize deployment, release or a validation bypass.

Live consumer feature admission now reproduces the reported bootstrap deadlock

Domus has reached an actual feature request, rather than only the offline reproduction in the original report:

Consumer issue: ✨🧑‍💻 - Implement Home Assistant identity and SQLite platform persistence domus#6
Failed run: https://github.com/vypdev/domus/actions/runs/40804494274
Failed job: https://github.com/vypdev/domus/actions/runs/40804494274/job/123220220687
Published diagnostic: ✨🧑‍💻 - Implement Home Assistant identity and SQLite platform persistence domus#6 (comment)
Configured feature parent: develop; reviewed merged consumer revision: 0012a172492515e282be09c37921f4014a451e64.
The workflow event's headSha is 8ee7e1a15e91c91b6204ca97e8808c3207dee008 because the issue workflow runs from the default branch. Do not confuse that metadata with proof that the configured development catalog was absent.
The run's setup log explicitly resolves vypdev/copilot@v3 to f5e5a4cf9a80248994469cd88ad55eecab5b95ca, the same audited source revision as the original report.

The maintainer applied in-progress to the correctly admitted feature issue. The Action then failed before ownership operations and explicitly reported that no specification or managed branch was published:

Pre-branch SDD gate failed: The SDD catalog is incompatible with the installed publication profile (owner-paths-invalid).
Error code: configuration.unsupported
Reference: e06de175-af62-4016-9d94-265e976258c5

This is not a queued job, a runtime-provisioning failure, an ambiguous native catalog, or a model's rejected draft. The failure occurs in the closed compatibility reader before model/ownership operations. Its SDK-v1 path-array check rejects an empty field other than workflows, without checking status: proposed:

copilot/src/domain/sdd_catalog_compatibility.ts

Lines 83 to 88 in f5e5a4c

    
           for (const field of PATH_FIELDS) { 
        
             const paths = entry[field]; 
        
             if (!Array.isArray(paths) || (field !== 'workflows' && paths.length === 0) 
        
               || new Set(paths).size !== paths.length 
        
               || paths.some(path => typeof path !== 'string' || !pathPolicy.isSafeRelativePath(path) || !pathPolicy.matchesFieldBoundary(field, path))) { 
        
               throw new SddCatalogCompatibilityFailure('owner-paths-invalid');

Updated deterministic facts

The consumer catalog still has eleven uniquely owned proposed capabilities. PR #5 added actual developer tooling, its executed tests and CI Check, so only delivery-quality now contains truthful partial implementation evidence. The other ten product capabilities remain unimplemented. Their entrypoints, code and tests arrays are correctly empty.

https://github.com/vypdev/domus/blob/0012a172492515e282be09c37921f4014a451e64/specs/catalog.json

Executing the unchanged original reader and validator against this snapshot, after verifying all seven cached upstream source blobs against their Git object IDs, yields:

{
  "capabilities": 11,
  "statuses": ["proposed"],
  "compatibilityFailure": {
    "name": "SddCatalogCompatibilityFailure",
    "reason": "owner-paths-invalid"
  },
  "validatorErrorCount": 30
}

All thirty validator errors are precisely the three empty implementation fields on those ten capabilities. No extra catalog error was returned. The decrease from 33 to 30 follows real tooling implementation; no evidence path was invented or reassigned to an unrelated capability.

Consequence and requested owner action

The consumer cannot begin its authorized identity/SQLite feature under the installed lifecycle: implementation must wait for the Action-owned branch, but pre-branch preparation requires implementation evidence for every proposed domain. The Action did not publish an expected ref/base suitable for the guide's exceptional branch recovery, so the contributor has not invented a branch or bypassed admission.

Please define and implement the supported truthful bootstrap route, preserving the original report's evidence/ownership/security acceptance constraints. Retrying this unchanged consumer would repeat the same deterministic prerequisite failure; please provide a concrete compatible fix or documented owner-approved route before requesting a retry.

Copilot source, installed resources, consumer catalog statuses/schema and gate behavior remain unchanged. Authentication/persistence design and planned cases can be prepared outside the checkout, but none is presented as implemented or as executed application coverage.

bugfix-777-sdk-proposed-capability-catalogs-have-no-truthful-greenfie…

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)

Progress: 95% — in progress

> Current status: [R1] Please investigate/reconcile the supported bootstrap contract, rather than blindly relaxing implementation/readiness validation. A supported route may require an explicit documented initialization lifecycle or status-aware evidence semantics. The reporter is not prescribing which policy is correct. — The patches define a status-aware bootstrap contract and document its lifecycle while preserving readiness checks.
[R2] Expected product behavior: a maintainer can initialize a new SDD-driven project with truthful prospective requirements and an explicit not-implemented/not-ready state, using a supported documented workflow. No synthetic source, empty wrapper tests, misclassified documentation paths, schema/status substitution or disabled gate should be necessary. — Proposed capabilities can have empty implementation arrays, with explicit not-implemented messaging and Draft readiness preserved.
[R3] 1. Define and document a truthful greenfield initialization route, including interaction with pre-branch SDD and Action-owned branch admission. — Documentation describes initialization through the documentation issue workflow, Action-owned branch, prerequisite review, and subsequent feature gate.
[R4] 2. A prospective document may remain explicitly not implemented and not Ready for implementation without fake implementation evidence. — The proposed status permits empty entrypoints, code, and tests without promoting readiness or fabricating eviden
[untrusted content truncated]

Next: [R19] "acceptance": "A deterministic fixture for a documented greenfield workflow validates prospective capabilities without fabricated implementation evidence, while implemented capabilities still require valid entrypoints, source, and tests; unsafe or missing paths and invalid readiness transitions are rejected with actionable guidance." — Independently verify that the deterministic workflow fixture passes and rejects unsafe or missing paths while retaining implemented-entry evidence requirements.

Merge pull request #795 from vypdev/bugfix/777-sdk-proposed-capabilit…

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.

Navigation Menu

Repository navigation

🐛🧑‍💻 - SDK proposed capability catalogs have no truthful greenfield SDD bootstrap route without implementation evidence #777

Is there an existing issue for this?

Which actions are affected?

Which platforms are affected?

Description

Reproducing the issue

Actual immutable consumer reproduction

Source-level cause

Evidence and boundaries

copilot Version

Relevant Log Output

Additional context and comments

Live consumer feature admission now reproduces the reported bootstrap deadlock

Updated deterministic facts

Consequence and requested owner action

1 remaining item

Issue closed — historical progress

Last assessment before closure (historical)

Progress: 95% — in progress

Issue closed: synchronization recommendation retired

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	for (const field of PATH_FIELDS) {
	const paths = entry[field];
	if (!Array.isArray(paths) \|\| (field !== 'workflows' && paths.length === 0)
	\|\| new Set(paths).size !== paths.length
	\|\| paths.some(path => typeof path !== 'string' \|\| !pathPolicy.isSafeRelativePath(path) \|\| !pathPolicy.matchesFieldBoundary(field, path))) {
	throw new SddCatalogCompatibilityFailure('owner-paths-invalid');

🐛🧑‍💻 - SDK proposed capability catalogs have no truthful greenfield SDD bootstrap route without implementation evidence #777

Description

Is there an existing issue for this?

Which actions are affected?

Which platforms are affected?

Description

Reproducing the issue

Actual immutable consumer reproduction

Source-level cause

Evidence and boundaries

copilot Version

Relevant Log Output

Additional context and comments

Activity

efraespada commented on Oct 29, 2026

Live consumer feature admission now reproduces the reported bootstrap deadlock

Updated deterministic facts

Consequence and requested owner action

1 remaining item

vypbot commented on Oct 29, 2026

Issue closed — historical progress

Last assessment before closure (historical)

Progress: 95% — in progress

vypbot commented on Oct 29, 2026

Issue closed: synchronization recommendation retired

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions