Decisions — flower

flower from brief #275 for · flower-orchestrator

❓ Merge #275 now?

brief #275 Track worktree/environment isolation metadata (DB-isolated vs code-only) in flower # Track worktree/environment isolation metadata in flower ## Problem (operator, 2026-07-05) We run many git worktrees across projects with DIFFERENT isolation...

#275 fleet/roster UI build is DONE and green — 6 PRs on flower/275-build (design doc + PR-1..6), full suite 1381 pass / 3 skip / 0 fail, pint clean. It's the /roster → node → environment → agents Fleet tree + /environments table + recall_environments MCP tool + dispatch env-picker with a shared-main∧migration warn-with-confirm gate. Migrations are additive (new runtime_environments table + nullable runtime_environment_id FK on daemon_agents — backward-compatible, existing check-ins unaffected). Design was already blessed via the design loop + your decisions #75/#76. Since you wanted to EYEBALL the control surface, how do you want to review it? (Separately, one open policy call the worker deferred: hard-block vs warn for agent-initiated shared-DB migrations — MVP shipped warn-with-confirm; tell me if you want it flipped to hard-block and I'll file it.)

Merge to MAIN + eyeball live Recommended I merge now, verify on real MySQL, you review it live at flower.home.legitphp.com/roster

Hold — I'll review the branch first I hold the merge; you review flower/275-build / the design doc before it lands on MAIN

Open in new tab ↗

flower from brief #196 for · flower-refine

❓ Conductor case

brief #196 Multiple project / cross-project support/usage How might we envision Multiple project / cross-project support/usage How might we envision something like that? A perfect example is right now - I have two projects, `lounge` and `...

For the conductor/lounge/vodmanager job-routing need specifically: agree flower's role is coordination/memory (multi-project briefs + cross-project recall), while the job-routing mechanism itself is conductor's code problem?

Yes — flower = coordination/memory; job-routing is conductor's code

No — I want to explore flower doing more here

Split it: track/coordinate in flower, but let's also discuss the routing design

Open in new tab ↗

flower from brief #196 for · flower-refine

❓ Grouping model

brief #196 Multiple project / cross-project support/usage How might we envision Multiple project / cross-project support/usage How might we envision something like that? A perfect example is right now - I have two projects, `lounge` and `...

For recall grouping, explicit or automatic?

Explicit operator-defined project GROUPS / meta-projects (name a set; recall scopes to it as a unit)

Automatic path/touch-based association (the scratchpad-1007 'touched projects' design)

Both — explicit groups layered on automatic touches

Not sure — recommend one

Open in new tab ↗

flower from brief #196 for · flower-refine

❓ Primary need

brief #196 Multiple project / cross-project support/usage How might we envision Multiple project / cross-project support/usage How might we envision something like that? A perfect example is right now - I have two projects, `lounge` and `...

What's the core want here — cross-project RECALL (read shared context across related projects), cross-project WORK coordination (briefs/dispatch spanning projects), or both?

Both — recall grouping AND cross-project work coordination

Mainly cross-project RECALL (combined memory/scope)

Mainly cross-project WORK coordination (briefs spanning projects)

Just exploring — surface options first, no commitment

Open in new tab ↗

tdr/thedarkroom from brief #54 for · anyone

❓ Prod FOS read OK?

brief #54 fos_imported_at / photos_first_cached_at — canonical "first import into FOS" (customer-delivery) timestamp + Uploaded→Delivered lag # fos_imported_at — canonical "first import into FOS" (customer-delivery) timestamp ## Goal Give every order an accurate **"first time its photos were imported...

The historical audit-log derivation can only be validated against production FOS (local staging has zero order.import-images rows). OK to run read-only dry-run queries against prod FOS audit_logs to validate coverage before writing?

Yes, read-only prod FOS is fine

Only via a replica/snapshot

Let's discuss access first

Open in new tab ↗

tdr/thedarkroom from brief #54 for · anyone

❓ 'Delivered' definition

brief #54 fos_imported_at / photos_first_cached_at — canonical "first import into FOS" (customer-delivery) timestamp + Uploaded→Delivered lag # fos_imported_at — canonical "first import into FOS" (customer-delivery) timestamp ## Goal Give every order an accurate **"first time its photos were imported...

Which moment is fos_imported_at? (a) first successful photo cache — first order.import-images success row / photos_cached_at first-set (always present, cleaner); or (b) the notification.created 'Order Ready' event (literal customer alert, ~seconds later, only for orders that notified). Recommend (a).

(a) first successful cache (recommended)

(b) Order Ready notification

Store both

Open in new tab ↗

tdr/thedarkroom from brief #54 for · anyone

❓ FOS migration OK?

brief #54 fos_imported_at / photos_first_cached_at — canonical "first import into FOS" (customer-delivery) timestamp + Uploaded→Delivered lag # fos_imported_at — canonical "first import into FOS" (customer-delivery) timestamp ## Goal Give every order an accurate **"first time its photos were imported...

If Approach A: are you OK running a Laravel 4.2 migration to add a column on the ~1M-row FOS orders table (online/INSTANT DDL in a low-traffic window) plus a ~3-line edit to the hot import path in Order.php, shipped via staging→cherry-pick→master→Forge and coordinated with Daniel? And is the column name photos_first_cached_at good?

Yes, proceed with FOS migration

Yes but different column name

No — avoid touching FOS (use B)

Open in new tab ↗

tdr/thedarkroom from brief #54 for · anyone

❓ Approach A vs B

brief #54 fos_imported_at / photos_first_cached_at — canonical "first import into FOS" (customer-delivery) timestamp + Uploaded→Delivered lag # fos_imported_at — canonical "first import into FOS" (customer-delivery) timestamp ## Goal Give every order an accurate **"first time its photos were imported...

FOS-first (add photos_first_cached_at to FOS + null-guard root-fix + backfill there, DAP copies) vs DAP-only (DAP derives from FOS audit_logs, no FOS change)? A is canonical/permanent but needs a FOS prod deploy; B touches no legacy code but leaves the overwrite bug in place. Recommend A given you liked it and the brief lives in the FOS project.

A — FOS-first (recommended)

B — DAP-only

Start B now, do A later

Open in new tab ↗