fix(sdd): sdd-attempt acquire/status reject valid change name resolvable by sdd-status

[hjagar]

Pre-flight Checklist

• I have searched existing open and closed issues and confirmed this is not a duplicate.
• I understand that PRs will be rejected if the linked issue does not have status:approved.

📝 Bug Description

gentle-ai sdd-attempt acquire and gentle-ai sdd-attempt status both fail unconditionally with Error: open native SDD runtime authority: invalid SDD change name, regardless of which change name is passed. This happens even for change names that gentle-ai sdd-status <change> --cwd <repo> --json resolves correctly (valid changeRoot, populated artifactPaths), in the same repo, on the same invocation shape. Tested with two different, syntactically valid change names (kebab-case, alnum + hyphens only) — both fail identically, so this is not specific to one change's name.

There is also a related flag-contract inconsistency: sdd-status accepts the change name as a positional argument (sdd-status <change> --cwd <repo>) and rejects --change position-style docs elsewhere suggest; sdd-attempt accepts --change <name> as a flag but rejects the same value positionally (unexpected sdd-attempt argument "<change>"). Discovering the right shape required trial and error, similar to what's already tracked in #1937 (no --help support on sdd-attempt).

🔄 Steps to Reproduce

1. In a git repo with an OpenSpec-backed SDD change already scaffolded (openspec/changes/<change>/ with proposal/spec/design/tasks present), confirm sdd-status resolves it:

   gentle-ai sdd-status <change> --cwd <repo> --json
   

   → returns a populated changeRoot and artifactPaths for that change.
2. Attempt to acquire a runtime attempt token for the same change:

   gentle-ai sdd-attempt acquire --cwd <repo> --change <change> --request-id <id> --work-unit <label> --evidence-goal <goal> --max-attempts 3 --max-changed-lines 800
   

3. Observe Error: open native SDD runtime authority: invalid SDD change name (exit 1).
4. Try the diagnostic-only status operation instead:

   gentle-ai sdd-attempt status --cwd <repo> --change <change>
   

5. Observe the identical error, for the same change AND for a second, unrelated change name in the same repo.
6. Try the change name positionally instead of via --change (mirroring sdd-status's accepted shape):

   gentle-ai sdd-attempt acquire <change> --cwd <repo> ...
   

   → Error: unexpected sdd-attempt argument "<change>" — rejected outright, no fallback to the flag form being tried instead.

✅ Expected Behavior

sdd-attempt acquire/status should resolve the same change identity that sdd-status already resolves successfully for the identical --cwd + change name, and return state: proceed (or a genuine, discoverable blocked/complete state per the compact contract) rather than a change-name validation error.

❌ Actual Behavior

• sdd-status <change> --cwd <repo> --json → success, valid changeRoot/artifactPaths.
• sdd-attempt acquire --cwd <repo> --change <change> ... → Error: open native SDD runtime authority: invalid SDD change name.
• sdd-attempt status --cwd <repo> --change <change> → same error.
• Reproduced with two distinct, unrelated, syntactically valid change names in the same repo — not name-specific.
• The Native Runtime Attempt Authority step in the SDD orchestrator workflow (sdd-attempt acquire before every runtime-bearing sdd-apply/sdd-verify launch) could not be satisfied at all; the SDD pipeline had to proceed without acquiring/settling runtime-attempt tokens for this session.

Environment

• gentle-ai version: 2.2.3
• OS: Windows 11, PowerShell 5.1 / Git Bash shell
• Artifact store: openspec (repo-local planning home)
• Related: fix(sdd): first sdd-attempt acquire on a fresh change returns blocked/authority_failure while status reports next_action: begin #2114 (different symptom — blocked/authority_failure JSON, not a hard CLI error), [bug] SDD subcommands do not expose usable help or complete flag contracts #1937 (no --help on sdd-attempt, same flag-discoverability pain point that made diagnosing this harder)

[aparragithub]

Additional sanitized occurrence:

Environment

• gentle-ai: v2.2.4
• Client: OpenCode 1.18.11
• OS/architecture: Linux x86_64
• Artifact store: Engram

Operation shape

A runtime-bearing SDD apply reached the mandatory native attempt-acquire gate. The change already had retrievable Engram proposal, spec, validated design, and tasks artifacts under one canonical change identity. Acquire was invoked once with bounded attempts and a 400-line mutation budget.

Outcome

• Attempt acquire exited before issuing a token with: Error: open native SDD runtime authority: invalid SDD change name.
• No apply actor was launched.
• No runtime-attempt token existed to settle.
• No repository mutation occurred; the SDD artifacts and candidate state remain preserved.

Expected

The attempt authority should accept the same canonical Engram-backed change identity used by the SDD artifacts and return a typed proceed, blocked, or complete state.

Actual

The authority rejected the canonical identity as an invalid change name before returning a typed state.

Minimal reproduction

1. Persist an Engram-backed change using a canonical identifier such as DEC-EXAMPLE-CHANGE, with proposal/spec/design/tasks available under the matching SDD topic namespace.
2. Invoke sdd-attempt acquire for that identity with generic request/work-unit/evidence labels and bounded attempt/line limits.
3. Observe the hard invalid-name error instead of a typed state.

This occurrence broadens the evidence beyond the original Windows/OpenSpec report: it reproduces on Linux with Engram-backed artifacts and a later 2.2.4 development build. This reports observed behavior only; no root cause is asserted.

[aparragithub]

Root cause confirmed, with a local reproduction. sdd-attempt and sdd-status enforce two different identity contracts for the same change.

OpenRuntimeStore validates the change name before it resolves anything else (internal/sddstatus/runtime_ledger.go:389):

if !validReviewBindingChange(change) {
    return RuntimeStore{}, errors.New("invalid SDD change name")
}

and validReviewBindingChange (internal/sddstatus/review_binding.go:786) applies this pattern (review_binding.go:24):

var reviewBindingChange = regexp.MustCompile(`^[a-z0-9]+(?:-[a-z0-9]+)*$`)

Lowercase kebab-case only. sdd-status applies no shape validation at all: it resolves whatever directory exists under openspec/changes/, or any Engram-backed identity (internal/sddstatus/status.go:353-375). On top of that, loadNativeRuntimeStatus (status.go:532-550) swallows the very same error, so sdd-status still exits 0 while sdd-attempt exits 1 for the identical name.

Reproduced on v2.2.4-28-g0cb9ff39, Linux, same repo and same invocation shape:

Command	Result
sdd-attempt status --cwd . --change add-user-auth	exit 0, valid RuntimeStatus JSON
sdd-attempt status --cwd . --change DEC-EXAMPLE-CHANGE	exit 1, invalid SDD change name
sdd-status DEC-EXAMPLE-CHANGE --cwd . --json	exit 0, populated changeRoot and artifactPaths

That covers the second occurrence exactly: a canonical Engram identity like DEC-EXAMPLE-CHANGE is uppercase, so it can never pass the regex, while every artifact under it resolves fine. The original Windows/OpenSpec report is not fully explained by this alone, since plain kebab-case does pass here. If the original change names can be shared (or checked for uppercase, underscores, dots, or a trailing character picked up from PowerShell quoting), that would confirm whether it is the same mechanism or a second one.

Worth noting for whoever picks this up: the strict pattern is not accidental. change is used as a filesystem path segment (<common-dir>/gentle-ai/sdd-runtime/v1/<change>) and as the openspec/changes/<change>/ prefix, and ReviewBinding.Change is hashed into bindingDigest. So widening the regex alone is not safe. On case-insensitive filesystems (macOS, Windows) DEC-X and dec-x would collide in the same ledger directory, and normalizing the stored name would invalidate existing bindings.

The shape that avoids both problems: accept the identity as given, persist it unchanged in the binding, and derive the ledger directory separately in a case-safe way, keeping the current v1/<change> path for names that already satisfy the existing pattern so nothing already on disk breaks.

Two smaller defects surfaced alongside it:

1. The error names neither the rejected value nor the expected shape, which is what made this take trial and error.
2. The flag-contract asymmetry in the report is real: sdd-status takes the change positionally, sdd-attempt only via --change.

Happy to open a PR for this once the issue is approved.

[dnlrsls]

Linked to #2238. Shared clause: SDD consumers must use one versioned resolved context for change, worktree, artifact, and native candidate identity.

This issue remains open with its own acceptance criteria and regression evidence, and is not being marked as a duplicate.

[teba-isea]

Additional sanitized occurrence on released gentle-ai 2.2.4 (macOS arm64, OpenCode client).

A hybrid SDD change with a human-readable multiword change identifier completed exploration and proposal, but native runtime status could not open its SDD authority.

Operation shape (no secrets):

1. Create planning artifacts for .
2. Run gentle-ai sdd-status <change> --cwd <repo> --json --instructions.
3. Do not launch an actor or mutate the authority after the failure.

Observed outcome:

• Status returned nextRecommended: resolve-blockers and reported the runtime authority unreadable.
• The diagnostic runtime surface reported: open native SDD runtime authority: invalid SDD change name.
• Compact attempt status classified the result as blocked(corrupt_authority).
• No implementation actor, reset, or authority repair was run; planning artifacts remain preserved.

Expected behavior:
The same accepted change identity should be usable by both SDD planning/status and the runtime-authority surface, or status should provide an actionable, safe migration/normalization path before planning artifacts are created.

Minimal reproduction:

1. Use a valid repository and a multiword human-readable SDD change identifier accepted by planning/status.
2. Create proposal-level artifacts for that identifier.
3. Query native SDD status and the diagnostic runtime status for the same identifier.
4. Observe that planning/status resolves the change while the runtime authority rejects it as an invalid SDD change name.

Privacy review: this report intentionally excludes raw argv, absolute paths, project names, usernames, hostnames, credentials, source contents, diffs, and environment values.

[hugovhs]

Additional sanitized occurrence on released gentle-ai 2.2.4.

Environment

• Client: OpenCode
• OS/architecture: Linux x86_64
• Artifact store: OpenSpec repo-local planning, with hybrid persistence configured

Operation shape

A change named tag_improvement completed exploration and proposal. Native SDD status resolved its proposal artifact but returned nextRecommended: resolve-blockers because the runtime authority was unreadable. No runtime-bearing actor was launched.

Observed outcome

• Planning/status recognized the change and its proposal.
• Runtime authority reported invalid SDD change name.
• The typed status result classified execution as blocked.
• No authority repair, reset, implementation actor, or repository mutation was performed; planning artifacts remain preserved.

Expected behavior

The identifier accepted by planning/status should be accepted by the runtime authority, or status should return an actionable safe migration path before workflow execution is blocked.

Minimal reproduction

1. In a repository, create a proposal-level OpenSpec SDD change using an underscore-containing identifier such as tag_improvement.
2. Query native SDD status for that same identity.
3. Observe that planning/status resolves the proposal while runtime authority is unreadable due to the invalid-name error.

Privacy review: this comment excludes raw argv, absolute paths, private project names, usernames, hostnames, credentials, source contents, diffs, and environment values.