Skip to content

Docs: vision, architecture, status sweep; tag-driven release machinery - #2

Open
Kiran01bm wants to merge 6 commits into
kiran01bm/phase-2-3-2-4-classifier-routerfrom
kiran01bm/oss-standup
Open

Docs: vision, architecture, status sweep; tag-driven release machinery#2
Kiran01bm wants to merge 6 commits into
kiran01bm/phase-2-3-2-4-classifier-routerfrom
kiran01bm/oss-standup

Conversation

@Kiran01bm

@Kiran01bm Kiran01bm commented Aug 4, 2026

Copy link
Copy Markdown
Collaborator

Summary

Top of the pg-sprite foundation stack: the vision and architecture docs, a status-accuracy sweep across the doc set, and tag-driven release machinery.

What

  • docs/vision.md (what pg-sprite is and is not) and the expanded architecture map with the five front-end stages.
  • Docs sweep aligning every design doc with the implemented Phases 1–2.4: implemented behavior reads as present, planned behavior carries its phase, decided questions (in-house schemadiff, Wasm parser, CDC strategy) no longer listed as open.
  • GoReleaser + tag-driven release workflow (v* tags → linux/amd64, linux/arm64, darwin/arm64 archives, CGO_ENABLED=0), zizmor findings fixed (no setup-go cache in the publishing job, verified action pin, no persisted credentials).

The stack

Foundation work lands as a reviewable stack, bottom-up (merge with merge commits, not squash, so children retarget cleanly):

  1. kiran01bm/p0-foundations — Phase 0: scaffold, dbconn + Aurora TLS, doc baseline, OSS governance
  2. kiran01bm/ci-foundations — CI matrix (PG 14–18), hooks, test-methodology registry, lint enforcement
  3. kiran01bm/phase-1-front-door — Phase 1: optimistic migrate, typed verdicts, logging principles
  4. kiran01bm/phase-2-1-2-2-diff — Phase 2.1–2.2: parse boundary, execute-and-introspect declarative diff, diff/fmt
  5. kiran01bm/phase-2-3-2-4-classifier-router — Phase 2.3–2.4: descriptors, classifier, router seam
  6. this PR — docs + release machinery

What lands next (separate PRs)

  1. Phase 2.5 — stable machine-readable plan JSON (the orchestrator seam); first module tag follows once it settles.
  2. Phase 3 — native executor: routed execution of classified safer sequences, CREATE INDEX CONCURRENTLY lifecycle, bounded lock retry, substitution/--force, progress.
  3. Later phases — the log-based, checksum-gated copy-and-swap backend.

@github-advanced-security

Copy link
Copy Markdown

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

  • The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
  • Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
  • You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.

Comment thread .github/workflows/ci.yml Fixed
Comment thread .github/workflows/ci.yml Fixed
Comment thread internal/testutil/postgres_tls.go Dismissed
Comment thread internal/testutil/postgres_tls.go Dismissed
Comment thread internal/testutil/postgres_tls.go Dismissed
Comment thread internal/testutil/postgres_tls.go Dismissed
Comment thread internal/testutil/postgres_tls.go Dismissed
Comment thread internal/testutil/postgres_tls.go Dismissed
…aration

MySQL lets authors assert the cost bracket (INSTANT/INPLACE/COPY) and
the lock impact (NONE/SHARED/EXCLUSIVE) and fails closed; PostgreSQL
has no such clause. State in the README, the planner package doc, and
the online-DDL reference that the planner proves both dimensions
before execution and routes to the safest sequence that exists.
Port the vision from the research doc set: pg-sprite as the go-to
engine for all PostgreSQL schema changes — the reliable, deterministic
execution layer under a GitOps front-end like SchemaBot, as Spirit is
for MySQL. Five pillars, success criteria, and explicit non-goals.
Break the planner box into its pipeline: parse, introspect, diff,
classify, lint — showing where the imperative and declarative
front-ends enter and that both converge on the same classify -> lint
tail. Add a per-stage table (package, input -> output, why it is a
separate stage).
Mirrors the spirit/schemabot release approach: v* tag push builds
linux/darwin amd64+arm64 archives with checksums via goreleaser and
publishes a GitHub release. Pure-Go cross-compile (Wasm parser)
verified for all three targets.
Comment thread .github/workflows/release.yml Fixed
Comment thread .github/workflows/release.yml Fixed
The design docs predate the execute-and-introspect decision and the
Phase 2 landings; sweep every doc so implemented behavior reads as
present, planned behavior is marked with its phase, and decided
questions (in-house schemadiff, Wasm parser, CDC strategy) are no
longer listed as open.
Disable setup-go caching (cache poisoning surface in an
artifact-publishing job), repin goreleaser-action to the real v6.3.0
SHA (the previous pin was v6.1.0 mislabeled), and stop persisting
checkout credentials.
@Kiran01bm Kiran01bm changed the title initial-commit - pg-sprite foundations Docs: vision, architecture, status sweep; tag-driven release machinery Aug 5, 2026
@Kiran01bm
Kiran01bm changed the base branch from main to kiran01bm/phase-2-3-2-4-classifier-router August 5, 2026 08:56
@Kiran01bm
Kiran01bm marked this pull request as ready for review August 5, 2026 23:25
@chatgpt-codex-connector

Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants