Repository navigation
Gate main publication and validate the production stack before promotion #189
Description
Active main promotion — 2026-10-24 UTC
running independently on Matthew's behalf while he works
Matthew explicitly requested completing the careful merge to main. The bounded correction is in progress with independent workflow, persistence and production acceptance review. No main merge or main protection change has occurred yet.
For source promotion, registry writes and unfinished release/deploy operations will be explicitly disabled. Implementing a validated exact-SHA publisher/deployer is tracked separately in #190; it is not being represented as completed here. The original release-publication acceptance item below is superseded for this promotion by that fail-closed boundary. The production-stack, persistent-authentication and actual final-main CI gates remain required.
The findings below preserve the original reviewed baseline and are historical evidence until verified by the correction's linked PR and results.
Main promotion needs explicit release gates before opening its PR or publishing images. The reviewed source is validated dev ef495eff15ed7aac51e72dc7a1db1bb96d2b3695; main was 775362eace0723c57b7ba3c7936645c9d0d36cb4 during this review.
These are read-only source findings, not newly executed production failures. Passing dev CI and the two local API image probes do not establish that the main-only nginx/TLS Compose gate, multiarchitecture publishing matrix, or deployment workflow works. No deployment, registry publication, main protection change, or production-stack run was performed for this review.
1. Image publication runs before validation
Docker Publish triggers on both main pushes and PRs targeting main. Its three-image, two-architecture matrix logs into GHCR and unconditionally sets push: true, without depending on CI. Main is the default branch, so its metadata includes latest; opening a main PR also attempts publication of PR tags. A failed validation does not prevent those writes.
Acceptance:
- Main PRs perform builds/checks without registry writes; login, image push, and stack-manifest publication are all guarded.
- Release publication consumes one explicitly validated commit SHA and waits for its required checks, including the production gate when selected. Failed or incomplete validation cannot move release tags.
- Verify event conditions without publishing first; keep existing main protection and non-author approval requirements.
2. Production smoke credentials, readiness, and outcome are inconsistent
The main/nightly/manual production job generates JWT/session secrets but provides no admin password. Production bootstrap generates a random password, while the smoke helper uses admin / graphdone. Compose does not forward admin credentials.
The readiness loop uses curl without HTTP failure checking or a health-status assertion, while the background build has no explicit success check. The raw smoke command inherits two CI retries. Finally, CI Success omits prod-smoke from its dependencies and result checks, so that aggregate can pass before, or despite, a failed production smoke job.
Acceptance:
- Use generated, private, CI-owned admin credentials consistently in Compose and the smoke helper; retain production password requirements and redact secrets from evidence.
- Detect build/start failure and require successful HTTP plus application/database readiness before smoke. Do not treat an HTTP error page as healthy.
- Run the existing strict smoke sequence with zero retries and no required skips, retain failure artifacts, and propagate the selected production job's result into the required aggregate/publication gate. Legitimate nonselected jobs must remain distinguishable from failures.
- Execute the corrected production gate once on the exact candidate in an isolated stack; retain source SHA, result, and cleanup evidence. The existing comment estimates roughly 45 minutes for a cold build, so schedule this deliberately rather than repeatedly rerunning it.
3. The SQLite volume does not match the workspace runtime path
Compose mounts sqlite_auth_data at /app/data. The API image starts npm in the server workspace, and SQLite resolves its file from process.cwd()/data/auth.db. That workspace path is /app/packages/server/data; bootstrap credentials use the same directory. The declared volume therefore does not protect these files against container recreation.
Acceptance:
- Align the persistent mount and the actual runtime data directory without replacing any existing user's volume.
- In a disposable stack, prove an owned account retains its ID and login after API container recreation with the same volume. Verify bootstrap credentials stay private and persistent; remove only the test-owned resources afterward.
4. Deploy is a placeholder and does not pin the validated source
The CI-completion staging path checks out without workflow_run.head_sha, so it can build a newer main revision than the successful run. Both staging and production use root Docker context without a Dockerfile override, but this tree has no root Dockerfile. Their deployment steps only echo success around TODO comments. The tag path also creates a GitHub release; none of this establishes a deployed service.
Acceptance:
- Either explicitly disable/mark these unfinished deployment paths as nonoperational, or implement a separately authorized deployment workflow. Do not report echo output as deployment success.
- Any retained build/publication path pins the validated SHA, uses locked installation and the intended existing Dockerfile, and cannot publish unvalidated source.
- Actual deployment remains a separate, explicit operation requiring environment-specific health and version verification; merging source alone is not deployment evidence.
Resume order
- Keep the reviewed candidate branch and this issue as the checkpoint. Do not open a main PR while its publish hook still writes to GHCR.
- Prepare a small reviewed workflow/fixture/persistence correction; first remove unintended PR publication and clarify the inactive deployment paths.
- Run focused checks, then one serialized production-stack gate and the disposable recreation check on the exact corrected candidate. Preserve failures and avoid unrelated broad reruns.
- Open the main promotion PR, retain required independent approval and existing protection, and merge only after the applicable exact-head gates pass. Publish or deploy only through the explicitly validated release path.
Activity
mvalancy commentedon Oct 23, 2026
Clean public checkpoint:
audit/core-main-promotion-20261023, headf784effca932aaae49534756e0c0878b093dd8a9.88ce10dc8c39b1687c180ff22db20744c4bf2996preserves parents main775362eace0723c57b7ba3c7936645c9d0d36cb4and validated devef495eff15ed7aac51e72dc7a1db1bb96d2b3695. No conflicts; its full tree and all 683 tracked entries exactly match validated dev.775362ea. No main PR was opened because its current hook publishes images; no main/protection/registry/deployment change was made. The standing admin exception remains scoped to dev.Resume with the focused corrections and acceptance order in the issue body, preserving the completed dev evidence. Re-read live main/dev refs before updating the candidate. Run the new production-stack/recreation evidence deliberately, then promote only after the release blockers and applicable review requirements are resolved. This is a committed, published handoff; there is no background release job or uncommitted implementation to recover.
mvalancy commentedon Oct 23, 2026
Clean closeout/checkpoint verification:
775362ea; dev isef495eff. No main PR was opened and no release publication or deployment was triggered.test-artifacts/audit-20261023/retained-baseline-patches/evidence directory. Corrected regressions and incident lessons remain in the published repository.The next work is the bounded resume sequence in #189, not an untracked continuation of this completed dev sweep.
mvalancy commentedon Oct 23, 2026
Continuing #189: running independently on Matthew's behalf while he works. Matthew explicitly requested that we finish the careful promotion to main.
Validated dev remains
ef495eff15ed7aac51e72dc7a1db1bb96d2b3695; main remains775362eace0723c57b7ba3c7936645c9d0d36cb4. Three isolated workstreams are addressing the bounded blockers: workflow guards/aggregate, authentication-volume durability, and strict production-stack acceptance. Independent review is active.The main-promotion scope will disable unvalidated registry publication and explicitly mark the unfinished deployment/release workflows unavailable. Main/PR image builds remain read-only. Implementing a real exact-SHA publisher and deployment is a separate release task, not a prerequisite for safely merging validated source. No release, registry push, deployment, or main protection change has occurred.
The first regression demonstrates the workflow defects: 14 failing / 8 passing cases on the current dev workflow; the correction passes all 22 focused cases. It tests selected/nonselected production outcomes (including failure, missing, cancellation and skip), aggregate wiring, and absence of registry/release writes. This is preliminary evidence; runtime, CI and independent review remain required before integration.
mvalancy commentedon Oct 24, 2026
Repair PR is now #191. Its composed source passed 204 harness cases and independent source review. Local production images built successfully; API/Neo4j health, owned graph save/readback/cleanup and same-ID login after API-container recreation passed before the strict browser stage began. Final production result and cleanup are still pending.
Review also caught raw browser traces in the planned public artifact directory. A separate four-file follow-up now allowlists only the top-level production report and redacted stage logs; it leaves runtime files and assertions unchanged. Its regression fails against the broad upload and passes with the correction. We will integrate it after the running source snapshot completes, then require final-head CI before merging.
mvalancy commentedon Oct 24, 2026
#191 now targets main directly, preserving normal main ancestry and all reviewed development work. This avoids an unnecessary intermediate dev merge/test cycle; it does not skip main validation.
Final candidate
d9278cbd7057b9d0d33f078c860596b4176b9b13differs from the successful local production candidateabc29d9only in two reviewed lesson/index documents. Independent complete-tree comparison verified 695 other entries identical by mode/type/blob. Main PR checkout isb985896b6f4b030fe4e6f1edc6e1e0335b731d4f, parents current main775362eplusd9278cb, with exactly the candidate tree.Main-target CI 40043858265, Comprehensive 40043858272 and Docker Build Validation 40043858271 are running. Actual Docker jobs are the reviewed read-only/no-publication jobs; the completed Neo4j build confirms both architectures and no registry exporter. Production CI is selected for this main PR.
The superseded dev-target CI40043184454 was cancelled while browser work remained; it is not counted as a complete pass. Human review was requested from the existing reviewers under main's unchanged protection. No main merge, protection change, registry publication or deployment has happened.
mvalancy commentedon Oct 24, 2026
All technical validation for main candidate
8a9c7512b5dedf4020d117887674d378de85667bis complete and independently verified. CI40044417579, Comprehensive40044417576 and Docker40044417642 all passed, including production stack, both image architectures and all browser gates. The actual PR merge tree exactly matches the candidate. Evidence links and counts are in PR #191.The authorized exact-head native admin merge was attempted:
GitHub rejected it:
At least 1 approving review is required by reviewers with write access. (mergePullRequest).Main remains
775362eace0723c57b7ba3c7936645c9d0d36cb4, with administrator enforcement enabled and one non-author review required. The standing permanent exemption is dev-only. Existing human review requests remain open, and the owner has been asked whether to extend that exemption to main under the same documented validation bar. No setting change, alternate identity, credential expansion, force push or policy-bypassing transport was attempted. Independent agent review is not a GitHub non-author approval.#189 stays open until the actual main merge and successful final-main CI. Local owned resources and six test image tags have been cleaned up; all 44 Core worktrees and the original Cloud checkout are clean, with original checkouts unchanged. Running independently on Matthew's behalf while he works.
mvalancy commentedon Oct 28, 2026
I am preparing a refreshed, owned composition in branch audit/core-main-refresh-20261028, preserving #191 history and current reviewed development changes. Initial conflict resolution keeps both strict production acceptance and runtime-image requirements. The newer server CAPTCHA policy exposed two failing old production-fixture contracts; the API harness now requests and solves fresh server challenges, with 19 focused contracts passing. Real HTTPS/browser/recreation acceptance and independent composition review remain required. This is preparation only: main, protections, publication and deployment remain unchanged. #216 dependencies remain under final acceptance.
mvalancy commentedon Oct 28, 2026
Portable checkpoint, published after the owner's request to keep work recoverable from another computer:
audit/core-main-refresh-20261028, frozen source6936283489293d5d230641f776064f6e33e8b26a.Resume from another machine with a normal fetch/checkout of the named branch; do not use the original user's dirty worktree or assume
/tmpevidence/private environment files exist. Canonical source lessons are committed under.agents/; this issue and #193 retain the acceptance and authority boundaries. Main work remains parked while #216/#219 visual work is completed.