Module openspec 

Import an OpenSpec change folder as a kranz ticket.

OpenSpec (github.com/Fission-AI/OpenSpec) authors each change as openspec/changes/<name>/ holding proposal.md (rationale and scope), specs/ (requirements as SHALL-style scenarios), design.md (technical approach), and tasks.md (an implementation checklist). Its README states that it deliberately avoids phase gates and does not enforce a workflow.

That non-goal is kranz’s goal, so the two compose: OpenSpec produces intent, kranz makes intent binding. This importer is the seam, and it runs ONE WAY. openspec/changes/ explains why work exists; the approved plan is what the validator judges. Syncing back would leave two sources of truth to drift the moment someone edits a spec mid-mission.

Two mappings carry the whole risk, and both are deliberate omissions.

tasks.md is not imported. It is the assistant’s own decomposition, self-reported and ungraded, and importing it would slip an unvalidated plan past the orchestrator — the one step that should be doing that thinking.

Spec scenarios never become acceptance hints. docs/tickets.md requires hints to be concrete and testable with a passed-count guard, because a bare test-name filter exits 0 on zero matches. “The app SHALL default to the system preference” cannot fail, so copying scenarios into hints would ship a vacuous assertion with every imported mission. They arrive as intent instead, and the orchestrator still has to propose commands that can fail.

Structs

OpenSpecChange

The parts of an OpenSpec change that survive the crossing.

Constants

ACCEPTANCE_PLACEHOLDER

What the generated ## Acceptance hints says instead of scenarios.

Functions

import_change

Import a change directory as .kranz/tickets/<slug>.md.

read_change

Read an OpenSpec change directory.