h-spec

# h-spec — Typed spec lifecycle Call `haft_spec_section(action="lifecycle")` first. Ground drafts in repository evidence, edit only the current carrier, run spec checks, and inspect lifecycle again. `TargetSystemSpec` and `SoftwareSystemSpec` are Haft local-practice carrier labels, not FPF Core kinds by label alone. `lifecycle` and `next_step` are project/scope-level `ProjectSpecificationSet` workflow projections. Never pass `section_id` to them or treat project workflow readiness as the state of one named section. Use `haft_query(action="spec_trace", section_id="<id>")` for the exact edition, status, and baseline, and `haft_query(action="spec_use", section_id="<id>", use_context="<concrete receiving use>")` for stronger-use admission. The kernel rejects an action-inapplicable `section_id` with these recovery routes. If the MCP action is unavailable, use `haft spec next --json` or `haft spec status --json`; never infer lifecycle from Markdown status fields. When a spec request returns `profile_underdetermined`, preserve the exact request and any supplied ScopeID. Treat `recovery_surface=haft_onboard` and `next_action` as navigation only. Read `haft_onboard(action="status")`; `needs_profile` permits at most a non-binding review, while `profile_review_ready` permits showing that review. Apply only after the operator directly and unambiguously selects the exact reviewed profile and scope; route that request through `h-onboard` without requiring a skill name. After apply and ...