flower
/
All feedback
Bug planned #56 routed · orchestrator

Can't assign a project to an existing brief via the UI → project-less briefs get stuck (the /projects-perf brief is unassignable and can't surface in project queues)

flower-refine · submitted 2 days ago

detail

What they reported

Operator reported (via brief #112, 2026-07-03): a brief about `/projects` being slow was created WITHOUT a project, and there is no UI affordance to assign a project to it now that it's live — so it's stuck in limbo (a project-less brief won't appear in project-scoped brief lists/queues/refine loops). Two fixes: (1) add a UI control on the brief detail (and/or inbox) to set/change a brief's project(s); (2) locate the orphaned project-less brief(s) and assign `flower`. Consider also: default/require a project at brief creation, and make project-less briefs discoverable (an "unassigned" filter). Note: MCP `brief_create` takes `projects[]` but there is no obvious tool to (re)assign a project to an existing brief either — a `brief_set_project` / reuse of the projects relation would help agents too. Separately, the same #112 flags the `/projects` "X/Y indexed" counter moving BACKWARDS (30/33 → 25/33) — captured as an in-scope fix in brief #112, noting here for ops awareness.

context

Structured context

{
    "also": "/projects indexed counter 30/33 -> 25/33 backwards (tracked in #112)",
    "routed": {
        "target": "orchestrator",
        "todo_id": 376,
        "authority": "autonomous",
        "routed_at": "2026-07-03T13:17:57+00:00",
        "routed_by": "operator:mike",
        "project_id": 16,
        "solo_todo_id": "696",
        "solo_project_id": "49",
        "coordination_queue": {
            "kind": "route_feedback",
            "drain": "orchestrator_recall_signals",
            "status": "pending",
            "latency": "<= one orchestrator heartbeat",
            "signal_id": 11
        },
        "default_project_id": 16,
        "coordination_signal_id": 11,
        "fix_spec_scratchpad_id": 367,
        "orchestrator_daemon_id": 12,
        "solo_fix_spec_scratchpad_id": "1058",
        "orchestrator_solo_process_id": 1015
    },
    "observed": "no UI to assign a project to an existing brief; project-less brief stuck",
    "source_brief": 112,
    "promotion_ledger": [
        {
            "at": "2026-07-03T13:17:57+00:00",
            "action": "orchestrator_routed",
            "target": "orchestrator",
            "todo_id": 376,
            "actor_ref": "operator:mike",
            "cycle_key": "2026070313",
            "fix_spec_scratchpad_id": 367
        }
    ]
}

state · operator override

Lifecycle

created
2d ago
triaged
2d ago
resolved
resolved by
ops

resolution
Owned by brief #112 (operator-reported) — not separately routed. Ops value-add: (1) LOCATED the project-less briefs for the 'assign flower' sub-task — 4 briefs have no brief_projects row: #8, #10, #74 (idea/refining), #13 (complete); all flower-related, assign project flower(16). (2) IMPORTANT cross-link: the same #112 note about '/projects X/Y indexed counter going BACKWARDS (30/33->25/33)' is a DIRECT SYMPTOM of the re-ingest churn ops just routed as todo #693 / spec #1053 (status file in file_signature re-ingests unchanged transcripts -> sessions flap indexed->summarized -> the indexed counter drops). Fixing #693 should fix the counter-backwards; #112's counter work should reference/dedupe against #693, not fix it independently. The UI 'set brief project' control + a brief_set_project MCP tool are the genuinely new asks in #56.

Delete permanently?