v3.17.0 — Runs on your team's tools

Ten days, 13 releases of fig and 16 of pm. The through-line is that both
plugins stopped assuming the tools, the conventions and the machine were ours.

The tracker is yours, and so are its rules

• Adapters are open: trackers/<type>.md and sources/<type>.md hold the
  calls, the config picks the file, and a type nobody bundled still runs.
  Chat and calendar are adapters too
• A ticket's sections come from the tracker's published template, in its
  order — not from this workflow's preference
• Where the tracker is governed by a written rules document, task.policy.doc
  is read before the first write of a session, and the rules win
• A task with no parent is a legitimate answer

A ticket now says when the work is finished

• Done conditions and a QA checklist, drafted from the spec entry and the
  design before anything is asked, and contract.level puts them on the
  ticket where review actually happens
• Every QA step traces to a done condition; a condition no step reaches is
  the gap the section exists to close
• A ticket filed before its requirement exists says so, rather than filing
  a confident placeholder
• One already-filed ticket can be brought to the template — one preview,
  one "go", never a batch

Handing over is a step with a gate

• /fig:handoff — lint is the gate, the person picks the sections, and the
  handover pins a Figma named version so every link carries &version-id=
• Violations come back blocking or warning. A gate that stops
  everything stops being a gate
• /fig:lint reads component sets, catching variants stacked invisibly on
  one another

A shared config knows its own age

• --origin reports symlink, work tree, commits behind, last fetch, and a
  SessionStart hook says so only when a copy has fallen behind
• --need stops a skill on a null it cannot run without; --authored
  stops one about to write on a value no config of yours mentions
• proto_publish declares its six keys rather than naming them in a comment

Starting from nothing

• /fig:setup and /pm:setup run as onboarding — what it produces first,
  a named ladder, questions in your words, "leave it blank" on every one
• Preflight leads with a verdict in plain words, and requires whatever tool
  your config names
• A starter path for a team with no conventions yet