F2.1a — Decide backend boundaries and record the walking-skeleton ADR

[Flow-Fly]

Parent: #133. Grandparent: #132 / #72.

Goal

Turn the recommended backend stack into an owner-approved architecture decision before repository or cloud structure is changed.

Decisions to record

• Keep the existing client at the repository root and add server/ and shared/ npm workspaces, or choose another layout.
• Node/TypeScript runtime and Hono server boundary.
• Postgres with Drizzle for metadata.
• S3-compatible object storage for project blobs.
• Local development through Postgres + MinIO.
• Initial Scaleway deployment target, region, domain shape, and operating-cost ceiling.
• Ownership of secrets, migrations, and deployment actions.

Scope

• Add a short ADR under the repository's existing documentation convention.
• Inspect current wip code and CI before finalizing the boundaries.
• Record alternatives considered and explicit non-goals.
• Define the contracts needed by the later F2.1 slices.

Out of scope

• No workspaces, dependencies, server code, database, storage, Docker, or deployment.
• Do not choose cloud resources without owner approval.

Acceptance

• The owner can approve or amend every material stack and deployment decision.
• Later implementation issues reference one stable decision record.
• The ADR makes clear which future changes are reversible and which create operational commitments.

Risk and routing

Risk: medium.
Worker-ready: no.
Execution boundary: decision-only.
Approval gate: owner approval is required before F2.1b or later implementation becomes ready.