[mstomar125]

Summary

resolve_reverse_segment (packages/core/src/playbook/validation.rs) had two silent-degradation points on a DB error:

• resolve_type_chain(...).unwrap_or_else(|_| vec![node_type]) collapsed the ancestor chain to just the concrete type.
• get_inbound_relationships's Err case did continue, silently skipping that candidate scope.

Either failure made a legitimate inherited reverse relationship name (e.g. node.blocked_by declared on an ancestor, used on a subtype instance) resolve to None, indistinguishable from a genuine typo. The caller then always reported this as BrokenPath, blaming the play's own expression for what could be a transient DB error.

Changes

• resolve_reverse_segment now returns Result<Option<String>, PlayValidationError> instead of Option<String>:
  • Ok(Some(source_type)) — a declared reverse name found (unchanged success behavior).
  • Ok(None) — a genuine miss (segment declared nowhere in the chain).
  • Err(PlayValidationError::SchemaResolutionFailed) — a DB error resolving the extends chain or reading a scope's inbound relationships, now propagated instead of silently degrading.
  • This mirrors the SchemaResolutionFailed pattern validate_schema_path already uses for its own forward-resolution tokio::try_join! failure a few lines above — same file, same established convention, not a new mechanism.
• Updated the one call site in validate_schema_path to match on the three outcomes: continue traversal on Ok(Some), fall through to the existing BrokenPath reporting on Ok(None), and push the propagated error + stop on Err (same as the forward-resolution failure handling immediately above it).
• Added 3 tests: two directly exercise resolve_reverse_segment's new Result contract (found-via-ancestor-chain → Ok(Some(..)), genuinely-undeclared → Ok(None)), and one locks in that a SchemaResolutionFailed from this call site is structurally distinguishable from BrokenPath (different kind(), correctly flagged as inconclusive via is_genuine_failure()).

Diff is scoped to only this function, its one call site, and new tests — no reformatting or changes elsewhere in the file (a sibling PR is concurrently touching different functions in the same file).

Test plan

• cargo test -p nodespace-core --lib playbook::validation — 98 passed, including the 3 new tests
• cargo test -p nodespace-core --lib playbook:: — 462 passed (full playbook module, no regressions)
• bun run quality:fix — clean (cargo clippy --all-targets -- -D warnings -D clippy::unused-async zero warnings)
• Pre-push gate (test:all + cargo build --bin nodespaced + test:e2e) passed in full on push

Closes #2885.

🤖 Generated with Claude Code

[mstomar125]

/pragmatic-code-review (MEDIUM effort) — result

Ran a review covering all 8 finder angles (line-by-line scan, removed-behavior audit, cross-file tracer, reuse, simplification, efficiency, altitude, conventions) plus an independent verification pass checking:

• Whether a sibling function (walk_path_against_schema in workflow_state.rs) has the same unfixed bug — it doesn't; separate function, separate degradation-tracking design, out of scope for this diff.
• Whether ensure_schema_cached plus a later get_inbound_relationships error leaves schema_cache in an inconsistent state — no, the two are documented as independent/uncoupled.
• Whether the Ok(None) => {} match arm at the call site correctly falls through to the existing BrokenPath push — confirmed, no skip or double-report.
• Whether resolve_type_chain's error could represent "unknown type" (which would make treating it as SchemaResolutionFailed/inconclusive wrong) — no, it only errors on a genuine DB query failure; an unknown type resolves fine via Ok(vec![node_type]), and the schema's existence is already confirmed by the caller before this runs.
• CLAUDE.md conventions — no violations.
• Confirmed via grep that resolve_reverse_segment has exactly one call site, matching the PR's stated scope.

Result: zero findings. No recommendations to address.

Re-Review Decision

Decision: NO RE-REVIEW NEEDED

Rationale: The review returned zero findings after full-angle coverage plus independent verification; no code changes were made in response (there was nothing to change). The PR is unchanged since this review ran.

The PR is ready for merge (pending final approval).