0.7.0

• Breaking, for 0.7.0: the suite is rebuilt around one run of decision points, with all state in your tracker and forge. /continuous-refactoring now leads from your open refactoring tickets to one opened merge request and, at every step — reconcile, Track choice, scan, filing tickets, selecting, design, implementation, merge request — shows what it found, the options and one recommendation. By default you decide each time; say in the call that it should do the run itself ("do it yourself"), or mid-run "carry on yourself from here", and it takes its own recommendations. The call also takes a Track, a ticket or a restriction ("only the Rector tools") in your own words. The suite keeps no state of its own any more: the config file, the bookkeeping document (local and remote), Ticket-create-mode, MR-create-mode and the Track cadences are gone, and so are the limits of two open merge requests and five open candidates. Tickets are found by their subject instead of a fixed label or title, a ticket you wrote yourself is picked up through a Candidate mark or by naming it, and a Track is scanned once — afterwards its tickets are the record. Where your project has its own skills for planning and implementing, a run recommends those and uses the suite's procedures as a fallback. Housekeeping is now one standing ticket made from a template in your repository, with a rhythm you choose, refactoring ideas left on it as comments, and its own command /continuous-housekeeping that can be scheduled and that an agent may start by itself. The suite is two skills, continuous-refactoring and continuous-housekeeping; the nine others are removed. The operations in docs/agents/issue-tracker.md change their cut: Search is new and required; Rejected, Blocked by and Housekeeping are new and optional; Bookkeeping, Filed date and Comment author and time are removed.

  A project onboarded on 0.6.0 needs three steps. (1) Run the onboarding again: call /continuous-refactoring, which adds Search to your ## Refactoring operations section and removes the bullets that no longer exist. (2) Delete the suite's old files under .scratch/refactor/ — config.md, bookkeeping.md, merge-requests.md and the folder out-of-scope/; they are no longer read. Tickets kept as local Markdown files under .scratch/refactor/issues/ stay. To keep your old rejections where they are instead of deleting them, name that folder under Rejected in the section (a rejection that should come back by itself once a PHP version is reached needs a line Blocker: PHP >= X.Y). Where the bookkeeping lived in a tracker issue, close that issue. (3) Remove the symlinks of the removed skills from your skills folder: refactor-loop, refactor-scan, refactor-prioritize, refactor-design, refactor-implement, refactor-learn, continuous-safety-net, continuous-guardrails, continuous-investigation. Nothing is migrated; the first scan of each Track rebuilds the worklist as tickets.

• The Housekeeping ticket's date line, template line and title are described by what they hold, not by a fixed wording: the onboarding words the Housekeeping bullet itself, and later runs read the due date and the template from the ticket in whatever words it states them.

• The suite no longer sets or reads the triage labels needs-info and ready-for-agent. Whether a ticket waits for an answer or is ready to work is read from its comments, so it works in a tracker without them. It stays compatible with other engineering skills, such as those of mattpocock/skills, and needs none of them.

• The onboarding now ends the run. Instead of offering to go on in the same call, /continuous-refactoring reports the onboarding as complete, points out the changes it left in the working tree (the tracker file) and recommends committing them and calling the skill again.

• The onboarding now tries its search and merge-request commands before it shows you the summary, not after writing the tracker file. When one fails, for example because your installed glab or gh is older, the onboarding asks about a working variant at that point, so the summary you confirm already contains commands that work and no second confirmation follows after writing. A run on its own takes a working variant it found itself; without one, it writes nothing and names the open question.