You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Follow-on design ticket from #5672 — its decomposition sketch names this as a separate design, and the parent's acceptance requires these tickets to be filed and linked. Filed in the 2026-11-04 gap pass (WS-F) so the design work exists and can be prioritised on its own merits; implementation timing is a separate decision, possibly months out.
What this design must settle
The Postgres-over-HTTP adapter: query translation scope — what subset of ID queries translates, and what is honestly refused.
Context from the parent
The parent design fixes the selective-sharing grants model, the existence-privacy rule, and the foreign data-store adapter contract. The parent issue carries the surrounding decisions this ticket must not re-decide; where this ticket's answer would change a parent decision, record that explicitly rather than silently forking it.
Decision record expected
Close this design with a recorded decision (on this issue or in a doc/ record linked from it): the chosen shape, the alternatives rejected and why, and the invariants implementation must hold. If the design splits further, file the splits and link them here rather than growing this issue.
Relations
Parent: #5672. Programme: epic #2056. Filed by WS-F (2026-11-04 ID design gap & expansion pass).
Scope: settle the Postgres-over-HTTP endpoint contract and the ID query shapes it supports. Unsupported shapes must be explicitly refused, not silently degraded. The parent asks which HTTP interface is canonical; this ticket should answer that for Postgres rather than re-decide the parent’s grants or existence-privacy model.
Current-main evidence:doc/2026-11-04T21-27-34Z_design_atlas_scaler_revision/2026-11-04T21-27-34Z_design_atlas_scaler_revision.md:463-474 accepts a portable PostgREST-style REST contract over standard Postgres and keeps Supabase-specific features out of the portable core. The queue broker (pkgs/fleet/crates/fleet-queue/src/queue_broker.rs:165-249,490-567) is a narrow hand-built PostgREST client, not a general SQL/query translator. Atlas’s SQL-over-HTTP pipeline is for libSQL/Turso, not Postgres (pkgs/atlas-search/crates/atlas-core/src/turso.rs:92-205). No general Postgres adapter or query-translation implementation exists on current main.
Design fork / recommendation: explicitly choose between PostgREST-compatible CRUD/RPC and an endpoint that accepts arbitrary SQL; do not imply general SQL translation unless the endpoint provides it. Define the supported filters/operators, ordering/limits, pagination/counts, types and errors, and whether joins, writes/RPC, or cross-request transactions are in scope. Add request/response contract tests with an injectable transport when implementation is planned.
No code changed and no runtime reproduction or tests were applicable. No additional issue or queue task was created: id: design: Postgres-over-HTTP adapter (from #5672) #5805 is already the follow-on design ticket; implementation timing remains a separate decision.
Disposition: triaged; issue #5805 stays open for the scoped design decision.
Activity
developing-today commentedon Nov 5, 2026
CODE-1488
dezren39 commentedon Nov 5, 2026
agent-note:v1 agent=repo-worker-code state=picked-up task=10208 lane=8ac61616-3815-4e7b-b33d-840a3829154a at=2026-11-05T12:46:45Z
Claimed queue task 10208 for triage. Revalidated issue #5805 as open; checking the parent design and any existing work before routing.
dezren39 commentedon Nov 5, 2026
🤖 Agent note · done (triage)
repo-worker-code), OpenChamber scheduled lane8ac61616-3815-4e7b-b33d-840a3829154a04f78696abfbdf6567f58e623d80520436f002faTriage findings (verified fresh 2026-11-05):
held,user/owned,do-not-merge,do-not-auto-edit) and no matching PR was found. Parent id: design: ID selective sharing and foreign data-store adapters v1 #5672 and adapter-contract issue id: design: foreign data-store adapter contract (from #5672) #5803 are also OPEN; no competing implementation was found.doc/2026-11-04T21-27-34Z_design_atlas_scaler_revision/2026-11-04T21-27-34Z_design_atlas_scaler_revision.md:463-474accepts a portable PostgREST-style REST contract over standard Postgres and keeps Supabase-specific features out of the portable core. The queue broker (pkgs/fleet/crates/fleet-queue/src/queue_broker.rs:165-249,490-567) is a narrow hand-built PostgREST client, not a general SQL/query translator. Atlas’s SQL-over-HTTP pipeline is for libSQL/Turso, not Postgres (pkgs/atlas-search/crates/atlas-core/src/turso.rs:92-205). No general Postgres adapter or query-translation implementation exists on current main.Disposition: triaged; issue #5805 stays open for the scoped design decision.