[twoimo]

Purpose

Promote the reviewed CI, local runtime, and data-workflow changes through the protected develop → data → main path.

The candidate spans 113 files, including earlier reviewed dependency, local Supabase, and index-deduplication changes. Its scope is broader than #3810–#3813; the complete diff remains part of this release review.

Exact candidate

Input	Verified value
Base main	36a6a3b507dbdbef9afd11dafe73c0efc4e29c80
Head data after #3818	53fb953f1b0d743305912db74e6ca344f2e4df30
Candidate tree	b1401742902c6a931528f8e0277162d034cf51c1
GitHub test merge	6aee3677c9c278951f7a4a347c42308e10feb1bf — same tree
Main ancestry	Current main is the merge base; 0 commits behind

Verified preparation

• docs(ci): record rollout and reconcile protected promotion ancestry #3814 verified the documentation-only CI lane at exact head 592e713c6968e07c254aaf30a12787e173d02609: 32 seconds, two successful and eight skipped job records. The skipped unit matrix is one unexpanded API record; this is not a controlled speedup measurement.
• chore(release): promote reviewed develop to data #3815 completed the first protected data promotion after all seven applicable workflows passed, including full web CI, Security, CodeQL, Release, Promotion Path, process boundaries, and the G014 source-catalog replay.
• chore(release): reconcile main ancestry for protected promotion #3817 reconciled the current main, data, and develop ancestry through a normal merge. Only the rollout record changed; runtime, tests, and configuration retained their bytes.
• chore(release): promote verified release ancestry to data #3818 passed its exact-head CI, Security, CodeQL, Release, and Promotion Path checks and merged normally. Web CI finished with all 17 jobs successful on attempt 2. The first Windows Bun sampler exited early; one targeted rerun retained the other 15 successful jobs and passed the benchmark, report verification, fixture tests, and final CI aggregate. The initial failure and its artifact remain available; the transient root cause is not established.
• Saved/read-back protection on develop, data, and main requires GitHub Actions Release, Promotion Path, CI, and Security. Strict freshness, conversation resolution, and no administrator bypass remain enforced; force pushes and branch deletion remain disabled.
• Supabase read-only verification at 2026-11-12 17:49:20 UTC confirmed the intended project was healthy and migration 20261112111043 matched the repository SQL. Eight redundant indexes were absent; six retained indexes, three protected notification indexes, and two UNIQUE constraints remained unchanged. No database write was performed in that verification.
• GitHub writer controls were read without changing them. The general write freeze and the separately approved hosted-pending lane have different admission rules. GitHub's production approval variable does not establish the Vercel production build environment.

Current exact-head verification

Verified on 2026-11-12 at 18:19 UTC: all seven applicable PR workflows succeeded for head 53fb953f1b0d743305912db74e6ca344f2e4df30. This head's web CI passed all 17 jobs on its first attempt.

Workflow	Exact-head result
CI (17 successful jobs)	Success
Security	Success
CodeQL	Success
Release	Success
Promotion Path	Success
Pipeline Process Boundaries	Success
G014 source-catalog contract	Success

The G014 source generate job succeeded; hosted-migration-ledger was skipped as expected because that separate lane is opt-in. That skip is not a hosted migration execution or proof of a new database write.

Post-merge verification of the same data head also passed: CI with all 17 jobs successful, Release, and CodeQL. Fresh branch and test-merge readback retained the exact main/data identities and candidate tree above.

The prior head's superseded CI was intentionally cancelled; its result is not used to approve this head. The later production execution and provider readback are recorded below.

Pending before main merge

• Complete this updated head's applicable checks and re-read main/data/tree identity.
• Recover visibility of the intended Vercel project through the user-approved browser fallback. The dashboard verifies the project; the connector still returns 404 and is not used as deployment evidence.
• Verify the actual Git-linked project/team, repository/root and production branch, current production identity, domain routing, health, and rollback plan (readback below).
• Before merging main, save and reload-read back disabled Auto-assign Custom Production Domains on the verified project, with the existing production routing and health intact.
• Perform a normal protected main merge after those operational inputs are verified: resulting main 27a2d2ae3675bd80c710a81e24b8cfe048baaf2c, tree b1401742902c6a931528f8e0277162d034cf51c1.

Provider readback — 2026-11-13 (KST)

• Verified in the signed-in Vercel dashboard: team team_OUj64KeLxJI3PkEbOaFZnorA (twoimos-projects), project prj_sau35J5uUtShIQ9OKofRtOVVnTSl (tzudong), Git repository twoimo/tzudong, root apps/web, production branch main.
• Current READY production: dpl_FHYEeE4Ev5CAfYPfhqzxhE9CYsGK, Git SHA 36a6a3b507dbdbef9afd11dafe73c0efc4e29c80, immutable URL https://tzudong-t01u4qmt1-twoimos-projects.vercel.app.
• /api/health on the immutable URL and www.tzudong.app returned ok: true and that exact Git SHA, deployment ID, and project ID. The apex tzudong.app retains its existing redirect to www.tzudong.app; this is not a no-redirect assertion for the apex.
• Saved Auto-assign Custom Production Domains as disabled and reloaded the Production environment page to verify the persisted setting. Existing production health still returned the current deployment after that change.
• The dashboard's vercel.json override retains ignoreCommand: node scripts/vercel-ignore-build.mjs, npm ci, npm run build, and only main/develop automatic Git deployment eligibility.
• The Instant Rollback dialog currently identifies dpl_FBG2GdPKaiDKxJ71nWmYBxddFn31 as the previous production deployment. No rollback was executed. Preserve it and the current FHYE… deployment during cleanup.
• The current FHYE… deployment is the named rollback target for the proposed release. On Hobby, it becomes the immediately previous production after this candidate is promoted; re-read that relationship after promotion and before any rollback. No other promotion may intervene.

Production execution status

The protected main merge is 27a2d2ae3675bd80c710a81e24b8cfe048baaf2c. Its post-merge CI passed all 17 jobs, CodeQL passed all five analyses, Release and Process Boundaries passed, and Dependabot graph update passed. All were attempt 1 on that exact resulting main SHA.

The Vercel production TZUDONG_APPROVED_PRODUCTION_SHA was set to that exact SHA, and the dashboard confirmed the environment-variable update. It is stored as a write-only Secret, so the saved raw value cannot be independently revealed; successful execution of the unchanged build guard remains part of the next build verification.

The initial automatic push deployment dpl_HmSZyJpDd5q2PFv9q1UpeVsmrnPd was canceled by the Ignored Build Step before the approval variable was updated. Its source is the exact new main SHA and its target is staged Production.

A same-commit Production redeploy was prepared with existing Build Cache enabled and Use project's Ignore Build Step still checked. The dialog confirmed that custom domains would not be assigned. Vercel then required account identity verification before creating the deployment. An initial email verification code was rejected as invalid or expired. The operator subsequently completed the same Vercel identity-verification flow. The successful build and promotion are recorded below; no credential values were retained.

This web diff contains CI helper/test changes only; app runtime, auth code, npm dependencies, health and deployment guard code match the previous production source. Verification should cover the exact staged build, public entry and deployment identity. No G009 signed authentication-evidence bundle is claimed.

Verify project, SHA, production target, READY state, and immutable URL while both live aliases still point to the captured production deployment. Run the required smoke checks, promote that same verified deployment ID, then read back provider, aliases, and live application identity.

Follow the staged-production runbook. Main-first development remains a coordinated follow-up policy change. Old-branch deletion and actual Mac cleanup have not been performed.

Completed production promotion — verified 2026-11-13 13:51 KST

Item	Observed result
Exact source	27a2d2ae3675bd80c710a81e24b8cfe048baaf2c; main/data/develop retain tree b1401742902c6a931528f8e0277162d034cf51c1
Verified production deployment	dpl_DKfxayPRbi1RXBuM8fRoaLJE1QNJ
Immutable URL	https://tzudong-eujke6zsy-twoimos-projects.vercel.app
Build	READY; dashboard duration 1m 40s; Production/Staged before promotion; build log confirmed the existing production ignore-build guard ran
Project	prj_sau35J5uUtShIQ9OKofRtOVVnTSl, twoimos-projects/tzudong, Git twoimo/tzudong/tree/main/apps/web
Promotion	The same tested Production deployment ID was promoted; no replacement build was used. The promotion dialog's Use project's Ignore Build Step was explicitly checked and read back before submission.
Public identity	https://www.tzudong.app/api/health returned ok: true, exact new SHA/deployment/project IDs, and host www.tzudong.app
Internal identity	https://internal.tzudong.app/api/health returned the same new SHA/deployment/project IDs and its own expected host
Apex	https://tzudong.app/api/health retained its existing redirect to www, then returned the new identity
Rollback	The post-promotion Instant Rollback dialog identifies dpl_FHYEeE4Ev5CAfYPfhqzxhE9CYsGK, SHA 36a6a3b507dbdbef9afd11dafe73c0efc4e29c80, as the immediately previous Production deployment. The dialog was cancelled; no rollback executed.
Future promotion policy	Production branch remains main; Auto-assign Custom Production Domains remains disabled after promotion. No DNS change.

Before promotion, both www/internal still returned the captured FHYE deployment. The immutable candidate health response matched all expected identifiers. The live app after promotion rendered the map and restaurant clusters, loaded 715 places, opened a restaurant detail with address/video/review data, and returned to the list. This is a targeted public-flow smoke, not exhaustive product or authenticated-admin certification.

The new and previous immutable vercel.app hostnames both showed the same Naver Map authentication failure, while the actual production domain rendered the map normally before and after promotion. This supports a hostname-specific integration restriction; the Naver allowlist itself was not read or changed. Staged-map success is not claimed. Source comparison confirms the web runtime, auth code, dependencies and deployment guard are unchanged in this release.

The build completed with four warning groups, including npm configuration/deprecation/install-script notices and Sentry navigation instrumentation/release-token notices. npm reported zero audited vulnerabilities. These warnings were not treated as a failed build or silently removed. At provider readback, the overview showed 0% error rate over its six-hour window (517 CDN requests, 29 function invocations); that window is not a long-term post-release guarantee.

All exact-main CI, CodeQL, Release and Process checks remain successful, with no source movement. No database mutation, DNS mutation, branch-protection bypass, project deletion, or Docker/volume action occurred during this release. Provider cleanup and main-first migration continue separately.