Skip to content

Epic: Protect/EQL v2 to Stack/EQL v3 guide for DynamoDB and Postgres #1540

Open
0 of 6 issues completed
Open

Description

@tobyhede

Background

Protect users need a tested upgrade to Stack for both DynamoDB and existing Postgres databases. EQL (Encrypt Query Language) v2/v3 names the stored-data generation, not the npm package major. The target is Stack 1.x's v3 API.

The current DynamoDB guide and cross-store tests are useful, but copying values into already-v3 Postgres columns does not prove a migration of an existing EQL v2 Postgres database.

Goal and delivery order

  1. Deliver the tested v2-to-v3 guide for both stores first. Include executable examples, passing live CI, accurate citations, supported mappings and exclusions, plus cutover and rollback instructions.
  2. Validate guide usability with the Migration Harness. Reuse the existing DynamoDB baseline, add a Postgres-v2 starting state, then use guide-only agent Runs and evidence-backed Editor revisions.

The guide milestone does not wait for the automated Loop. Migration to EQL v4 comes afterwards. PRs #1496 and #1497 cover later v4 migration work and are not dependencies of this guide.

Authoritative specification

The full architecture, requirements and acceptance contract remain in ADR PR #1575, including its approved v2-to-v3 priority amendment:

This epic tracks delivery; it does not duplicate the specification. The design was accepted in merged PR #1575; implementation completion is tracked separately.

First milestone: tested guide

Both can start from #1519; neither depends on harness automation or v4.

Second milestone: guide usability

Existing baseline ticket acceptance is retained. Open PRs are not treated as completed issues.

Delivery status — 2026-11-12

The final source guide is #1620 at 0ecabc3f62ee8a117c467981ce00d312e6cfc636, SHA-256 46106cc0a71dbeb757bcb0b3889c6fc5741bac201afe807ed8cde0a035d3d649. It now includes the tested PostgreSQL dependency preflight and explains safe repeat-conversion refusal. Source-guide CI passed. Publication is prepared in draft cipherstash/docs#118, signed 33e92186fa1d1f1376b07b9b1d62323452aab40f; build, types, content, links and source-equivalence checks pass. Nothing is deployed.

Fresh guide-only evidence

One fresh sample per store passed at harness 5261d3a5c0ae6a4750a7a1102d08436a1d314725 against the same guide hash above, using the existing Colima harness VM outside CI:

Procedure Run ID Oracle checks Friction Model turns
DynamoDB 9b12892a-7386-4b2b-afd9-11952a18c43b 24 passed valid empty list 11
PostgreSQL v2-to-v3 c268ecef-4c0a-4114-b2a3-bb16a9efc4cb 15 passed valid empty list 9

Runtime: Claude Code 2.1.322, resolved model claude-sonnet-5-5. Both retained complete private command/response artifacts. Independent review confirmed the actual guide-read response hash, use of the staged friction schema, no supplementary documentation supplied to the model, and no successful forbidden-access events. Filesystem README events remain conservatively marked possible; npm extraction produces those events, and command/response review is the evidence for the guide-only claim.

Report SHA-256 digests: DynamoDB 2c081ffc88daed4969d64907a87fe8fbad5f3a20f5efd7ea00d9232ca439587b; PostgreSQL 52fe3656562fda47c371e9a2a634e97de2733afa80dc7bac067f9ff0694e0ded. Raw artifacts remain private; secrets are not published.

Earlier attempts remain recorded with their original outcomes: PostgreSQL exposed the missing inline preflight, and a subsequent DynamoDB attempt passed behavior but produced an invalid section slug. The harness now supplies its exact section catalog/schema; no historical failure was relabelled.

Remaining work

These are one clean sample per store, not ADR convergence or customer staging proof. #1538/#1539 remain unimplemented. Customer schema/query inventory and actual AWS/PostgreSQL operational rehearsal, including cutover and rollback, remain required before customer-specific sign-off.

Harness integration remains pending required reviews and the acceptance-evidence follow-ups below. Deterministic CI at the schema-update heads reproduced an intermittent unmatched vfork observer continuation before behavior checks; signed repairs 62b09150f and 9ed2ff135 supply explicit PID tracing and identify the actor independently of strace's temporary capability-probe children. A red regression reproduced the helper-PID failure; independent review, 31 supervisor tests, 131 base tests and 220 combined tests pass locally (21 credentialed tests deferred to CI). The preceding heads repeatedly failed on missing actor-exit records, despite one passing retry. Current adapter head 7e12eaa0d09b8e0f28d7335e765109b975ab95cb passed current-head CI. All nine isolation and nine Test JS workflows across the five repair heads passed without retries. Both PostgreSQL branch logs show 224 passing harness tests, and both adapter logs show 241; all include the complete 21-case live matrix with no harness skips. The successful model evidence above belongs to its recorded harness revision and does not validate a later repair. No merge bypass, real-model CI workflow, paid host, VM restart or production data change was used.

Acceptance audit: four #1537 isolation criteria remain partially evidenced. Follow-up proof must cover each Protected Resource class, actual Oracle/foreign-Run/model-service targets, Docker socket absence or connection denial (the current probe only attempts a file read), and canary absence across actor-visible mounted files. These are evidence gaps, not demonstrated escapes. Startup supervision and active broken-monitoring/forbidden-access controls are evidenced at the recorded model-run revision; later tracing revisions require separate CI validation.

Activity

  1. changed the title [-]Spec: Migration Harness for the Protect.js → Stack DynamoDB upgrade guide[/-] [+]Epic: Migration Harness for the Protect.js → Stack DynamoDB upgrade guide[/+] on Nov 8, 2026
  2. changed the title [-]Epic: Migration Harness for the Protect.js → Stack DynamoDB upgrade guide[/-] [+]Epic: Protect/EQL v2 to Stack/EQL v3 guide for DynamoDB and Postgres[/+] on Nov 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    SDKready-for-agentFully specified and ready for an AFK agent

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions