feat(directives): amendment lifecycle — inactive status, new draft, before/after diff (#113)

Stage 4 of the doc-mode revamp. Closes the loop on living-spec contracts:
once a contract ships (PR raised) it becomes 'inactive', editing it kicks
off an amendment cycle, the planner sees the previously-merged content as
context, and "New draft" lets users abandon amendment and start the next
contract on a clean slate.

## inactive lifecycle

- New status `'inactive'`. Set automatically when `update_directive` detects
  a `pr_url` transition None → Some, alongside the revision snapshot
  (set_directive_inactive: idempotent, only flips active/idle/paused).
- `update_directive_goal` extends its CASE flip to include 'inactive', so
  editing a shipped contract's goal reactivates it for the planner.
- Frontend: `DirectiveStatus` gains 'inactive'; STATUS_DOT and the legacy
  STATUS_BADGEs (DirectiveDetail, DirectiveList) get color/label entries.
  Sidebar sort puts inactive after draft / before archived.

## Amendment diff to the orchestrator

`build_planning_prompt` takes a new `previous_merged_revision` parameter.
When set, it prepends an "AMENDMENT TO A PREVIOUSLY-MERGED CONTRACT" header
that shows the merged content and the amended content explicitly, with
guidance to plan a delta rather than a from-scratch rebuild. Both the
planning and replanning phases call `get_latest_merged_revision` and pass
it through.

## "New draft" affordance

- New `repository::reset_directive_for_new_draft`: clears goal to '',
  status → 'draft', detaches pr_url / pr_branch / orchestrator linkage.
  Past revisions stay in directive_revisions as history.
- New `POST /api/v1/directives/{id}/new-draft` handler.
- DirectiveContextMenu surfaces "New draft" only when status === 'inactive',
  via an optional onNewDraft callback (legacy tabular UI doesn't have to
  wire it up). After reset, the page navigates to the contract so the user
  starts typing the next iteration immediately.

## PR-state-aware updates

The user's spec — "open ⇒ update, merged ⇒ new PR, closed ⇒ new PR" — is
already implemented in `build_completion_prompt`'s `gh pr view` runtime
check, so no code change was needed here. The amendment cycle naturally
flows through it: inactive → goal save → status flips to active →
phase_replanning spawns a planner → completion task picks up the existing
pr_url, sees the GitHub state, and decides update vs new PR accordingly.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

1 files changed, 1 insertions, 0 deletions

diff --git a/makima/src/server/openapi.rs b/makima/src/server/openapi.rs
index e3ff757..e6d4547 100644
--- a/makima/src/server/openapi.rs
+++ b/makima/src/server/openapi.rs
@@ -131,6 +131,7 @@ use crate::server::messages::{ApiError, AudioEncoding, StartMessage, StopMessage
         directives::skip_step,
         directives::update_goal,
         directives::list_directive_revisions,
+        directives::new_directive_draft,
         directives::cleanup_directive,
         directives::create_pr,
         // Order endpoints