Title-review at induction — design note (v0.1)

Version: 0.1 Date: 2026-06-02 Status: Design note — REPORT ONLY. Not scoped, not built. No UI-as-form. No creation-flow code changes proposed here; this maps the feature against the already-investigated flow + constraints so Marvin can scope it. Subject: Let the operator review/confirm or rename the auto-derived engagement title at creation/induction time (Companion-mediated), instead of only via a later rename.

Grounding (established facts, not re-derived here)

• The title is derived silently, server-side, at commit — _create_engagement (creation.py:856) calls derive_title_from_seed(what_the_work_is, operator_supplied_name=seed.additional_assertions.get("engagement_name")). The operator never sees or confirms it pre-commit.
• derive_title_from_seed (title.py): if additional_assertions.engagement_name is present and non-blank → use it (clamped to 80 chars); else derive from what_the_work_is (first sentence, capped 80).
• The conversational creation flow reaches phase31_status == "ready_for_review" (converse.py:394) with review_project_draft / commit_project_draft intents (:103, :398) — the operator reviews the draft seed before commit.
• Title is a UI label distinct from the seed's substantive assertions (title.py); on a committed engagement it lives on the engagements.title column, not the seed/event log (verified on E0060).
• Constraints already cleared: must be Companion-mediated (Phase 55 conversational creation + §F "settings via the Companion only"); honors v0.9 operator-approves-transitions / AI-as-faithful-clerk; the seed (v0.9) is silent on title.

1. Insertion point

Recommendation: fold the title-confirm into the existing ready_for_review review turn — as one element of the draft the operator is already reviewing — rather than adding a separate round-trip turn.

• The operator is already at ready_for_review reviewing the draft seed ("I've drafted your project, but N things need your input…"). The would-be title is naturally one more reviewable element of that same draft. Folding it in avoids an extra turn and keeps the flow tight.
• It fires before commit_project_draft / create_engagement_commit — i.e. the operator confirms/renames as part of (or immediately after) the draft review, and the chosen name is on the draft seed by the time commit runs.
• Implementation note (read-only computation): surfacing the would-be title at review time requires computing derive_title_from_seed on the draft seed before commit. That's a pure, read-only function call (no state change) — it can be invoked at review time without altering anything.
• Alternative (open question, §6): a dedicated extra Companion turn purely for the title. Trade-off: cleaner separation, but an extra round-trip. Recommend folding-in unless Marvin prefers the explicit step.

2. Proposed Companion wording — MARVIN MUST APPROVE (Companion voice)

This is the part that needs Marvin's sign-off; two options, neither locked:

Option A — folded into the review turn, single line: > "…and I'll title it "{derived title}". That work, or would you like to call it something else?" > — appended to the existing "here's your draft, N things need your input" review turn.

Option B — its own sentence within the review turn, more explicit: > "For the name, I'd go with "{derived title}" (drawn from what you described). Keep it, or tell me a different title."

Operator-response handling (same for both):

• Accept (e.g. "that's fine", "keep it", or just proceeds to commit without naming): keep the derived title — do not write engagement_name; commit derives as today. (Default / no-op path.)
• Provide a new name (e.g. "call it Fenwick's care log"): write that string to the draft seed's additional_assertions.engagement_name; commit's derive_title_from_seed then honors it.
• No title mention (operator only addresses the other review items, then commits): treated as Accept — keep derived.

(Voice caveat: the examples above are placeholders in the existing Companion register; final phrasing is Marvin's call.)

3. What writes engagement_name, and when (pre-commit, safe)

• The creation-flow converse handler, on resolving the title-review (operator supplies/changes a name), writes additional_assertions.engagement_name = <operator name> onto the draft (candidate) seed — before commit_project_draft fires.
• This is a pre-commit edit of a candidate seed: per the Memory-lifecycle commitment, before commit retraction/edit is silent (the assertion never existed) — nothing is committed, no governance-bearing event, no induction. Safe.
• At commit, derive_title_from_seed reads engagement_name and uses it (clamped) → engagements.title. So the operator's chosen name flows through the existing derivation path; no new title-write path is introduced.

4. Edge cases

• No name given → keep derived. engagement_name stays absent; derive_title_from_seed falls back to what_the_work_is. (Exactly today's behavior — E0060 is this case.)
• Over-80-char name → derive_title_from_seed already _clamps operator-supplied names to 80 (_MAX_TITLE_LEN). Decision (§6): silently clamp, or have the Companion note it ("that's a bit long — I'll shorten it to '…'"). Recommend a brief Companion acknowledgement over silent truncation.
• Empty / whitespace name → treated as "no name": derive_title_from_seed requires operator_supplied_name and .strip(), so blank/whitespace falls through to the derived title. (Also matches the post-commit COALESCE(NULLIF(title,''), …) guard.)

5. Settled-commitment touches (beyond what's already cleared)

• Companion creation-flow vocabulary gains a title-confirm element. This stays inside Phase 55 conversational creation and the §F "via the Companion only" pattern — consonant, not a new departure. (Contrast: a standalone title-edit form during creation WOULD diverge — explicitly out of scope.)
• One new behavioral subtlety to flag: when the operator supplies a name, it is now recorded on the seed as engagement_name. So unlike E0060 (where engagement_name is absent), future engagements created this way will carry the operator's name on the committed seed. That is consistent with corrections-not-smoothed — the seed records the operator's intent at creation; any later rename still uses the column and leaves the seed's engagement_name intact (column is the display source). No conflict; flagged so it's a conscious choice that the seed becomes title-bearing at creation.
• No seed substantive-assertion commitment is touched — title is a UI label; engagement_name lives in additional_assertions, not the core seed fields, and is edited pre-commit.
• No other settled-commitment touch identified.

6. Open questions for Marvin (decide before scoping)

1. Insertion shape: fold the title-confirm into the existing ready_for_review turn (recommended), or a dedicated extra turn?
2. Companion wording: approve Option A or B (or supply preferred voice). This gates build.
3. Over-80 handling: silent clamp vs Companion acknowledges-and-shortens?
4. On Accept, record the derived name on the seed or leave it absent? Recommend leaving absent on plain-accept (minimal seed, matches today); only write engagement_name when the operator actively names/renames. Confirm.
5. Scope of paths: apply to the conversational ready_for_review flow only, or also the non-conversational creation paths (Phase 53 discovery-to-seed extract, Phase 54 commit-from-brief) that also derive titles silently at commit?
6. Trigger condition: always offer the title-confirm, or only when the title was derived (no operator engagement_name already supplied in the conversation)?

Report only. No flow code changed, no UI designed as a form, nothing built. Pairs with the post-commit rename path (PUT /engagements/{id}/title, operator-only, metadata-only) already in the engine.