User Story

As an adopter running /handover on an external project, I want the skill to score the project's harnessability and warn me about adoption blast-radius before I commit, so that I know upfront whether Rex's architecture handbooks will be advisory-only on this codebase (and adjust expectations accordingly).

Acceptance Criteria

• /handover adds a "Harnessability assessment" step early in its flow (after static discovery, before the registry write)
• Assessment scores at least these dimensions:
• Type safety — TS strict mode? Sorbet/RBS for Ruby? Python mypy configured? → strong / partial / none
• Module boundaries — DDD layers detectable? Clear src/lib/test split? Packwerk-style enforcement in Ruby? → strong / partial / flat
• Framework opinionation — does the framework abstract persistence / HTTP / DI? (Spring/Rails/NextJS → strong; raw Node/Go → moderate; raw scripts → weak) → strong / moderate / weak
• Test coverage signal — coverage tooling configured? CI threshold? → present / absent
• Lint baseline — ESLint/RuboCop/golangci-lint configured? pre-commit hooks? → present / absent
• Each dimension gets a 1-line rationale citing the evidence (e.g. "TS strict mode: ON — tsconfig.json:6 strict:true")
• Overall harnessability verdict: high (most dimensions strong) / moderate / low (legacy / weak boundaries / no type system / no test infra)
• For low scores, the skill explicitly warns: "Rex's architecture handbooks will fire advisory-only on this codebase. The blocking gate (ENFORCEMENT: blocking) will generate false positives. Recommended: adopt as advisory-only, plan a follow-up to add the missing scaffolding (typescript strict, lint baseline, etc.)"
• The score lands in projects/<name>/handover-assessment.md so the assessment travels with the project record
• AgDR documents the scoring dimensions + thresholds (these will need tuning over time)

Design Notes

industry harness-engineering "ambient affordances" framing: structural properties of the codebase make it more or less governable by an inferential agent. A Spring app abstracts away details Rex doesn't have to worry about; a tangle of scripts forces Rex to reason about everything. We're already detecting some of this implicitly during /handover; this ticket makes it explicit, persistent, and tied to expectations about what Rex can confidently enforce.

The score is advisory to the operator, not a blocking gate. Even a "low" project is still adoptable; the operator just walks in with eyes open.

Risk: scoring is subjective. Mitigation: ship with conservative thresholds + iterate based on real adopter feedback. The AgDR captures the v1 thresholds explicitly so future tuning has a baseline.

Risk: legacy adopters feel judged. Mitigation: the warning language is "Rex's gates won't fire reliably here, and that's a property of the codebase, not your team. Here's the upgrade path." Not "your codebase is bad."

Out of Scope

• Auto-fixing low-harnessability issues (e.g. adding TS strict mode for the adopter)
• Per-team or per-stack scoring weights — v1 ships with one global weighting
• Tracking harnessability score over time (interesting for v2.0 — "this project went from low → moderate after the typescript-strict migration")

Glossary

Surfaced 2026-05-19 reading industry harness-engineering article. v1.5.