Spike: additional deployment targets (Docker/SQLite, PostgreSQL)

[burakdede]

Parent epic: #8 (post-v0.1 backlog)

Context

§16.4 lists possible sibling deployment targets (Docker + filesystem/SQLite, PostgreSQL + object storage, AWS Lambda/ECS + S3, Kubernetes, Vercel) and states plainly that they are not v0.1 deliverables. §16.2 says external plugin support should wait until two or more real third-party adapter needs reveal a stable contract.

Post-v0.1 spike. Do not build a target before demand is evidenced.

Spec references

§16.4 Future targets, §16.2 No dynamic plugin loader in v0.1, §16.3 target contract.

Scope

In: a timeboxed evaluation of the DeploymentTarget contract against two additional target shapes (self-hosted Docker/SQLite and PostgreSQL + object storage), producing a findings document and follow-up issues.
Out: implementing a target in this issue.

Design notes

• The point of the spike is to discover whether §16.3's contract survives contact with a second and third backend, and specifically whether FTS5-equivalent lexical parity is achievable (PostgreSQL full-text search has different ranking semantics, a real risk to the "same logical build everywhere" promise).
• Findings should state explicitly which capabilities each target could honestly advertise, per §16.3's capability-loss rules.

Acceptance criteria

• Document evaluating Docker+SQLite and PostgreSQL+object-storage targets against DeploymentTarget (§16.3), naming every place the contract would need to change.
• Lexical parity analysis: can each target reproduce the build's ranking within a documented tolerance, and if not, what capability set can it honestly advertise?
• Assessment of whether a stable public adapter contract has emerged (§16.2's two-adapter threshold) with a recommendation for or against a plugin API.
• Effort estimate and prioritization recommendation per target.
• Follow-up issues filed for whichever target is chosen, or an explicit recorded decision not to proceed.
• Timeboxed and closed with a written recommendation either way.

Tests / verification

• Prototype-level verification only: a throwaway projection proving or disproving lexical parity for the PostgreSQL case.
• Findings reviewed and recorded as an ADR entry (§23).

Dependencies

Blocked by the v0.1 release (#102) and Cloudflare completion (#93).

Definition of Done

A written, evidence-based recommendation exists on whether and how to add a second deployment target, with follow-up issues or a recorded decision not to.