chore(release): prepare v1.0.11 — version constants, CHANGELOG, PLAN (not tagged) - #65
Merged
Conversation
Bumps all four version constants -- frontend/package.json, site.ts::APP_VERSION, backend/pyproject.toml, settings.py::VERSION -- and relocks uv.lock, which records the root package version. Both drift guards pass at 1.0.11: the v1.0.7 frontend pair and the backend pair added in #63, which is the first release where the backend half is actually enforced. Promotes CHANGELOG [Unreleased] to [1.0.11] and adds the PLAN.md version-map row plus a slice section recording what shipped, what was deliberately not done, and the finding that was investigated, fixed and then withdrawn. Dry-ran release.yml's own awk extraction against the new heading: returns the [1.0.11] section and stops cleanly at [1.0.10]. That is the check the v1.0.6 missing-heading incident would have needed. Stops short of the tag and the release -- both are operator steps.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
The preview for 9c8a06b failed in 1.2s with BUILD_FAILED / "Resource provisioning failed" and produced zero build-log events -- it never reached a build step. Retriggering to distinguish a transient platform error from a persistent preview-environment config problem. No file changes.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Everything the v1.0.11 release ritual needs, stopping before the tag. Tagging and publishing stay operator steps.
The six fixes are already merged and prod-verified — this only labels them.
Version constants — all four
frontend/package.jsonfrontend/src/lib/site.ts::APP_VERSIONbackend/pyproject.tomlbackend/app/settings.py::VERSIONuv.lockrelocked — it records the root package version, so leaving it would fail v1.0.10'suv lock --check.This is the first release where both drift guards actually bite. v1.0.7 added one over the frontend pair; #63 added the backend pair this session, after finding
pyproject.tomlseven releases behind. Both pass at 1.0.11, which is what makes "all four bumped" a verified claim rather than a careful-editing claim.CHANGELOG
[Unreleased]→[1.0.11] — 2026-07-31, with a lead paragraph naming the actual cause: enabling Cache Components in v0.8.6 changed leave-and-return behaviour repo-wide, and one root cause was behind four separate user-visible problems. Two### Internalentries added for the backend version drift and the console-noise-list audit.Dry-ran
release.yml's own awk extraction against the new heading:Returns the
[1.0.11]section and stops cleanly at[1.0.10]. That is the check the v1.0.6 missing-heading incident would have needed, and the empty[Unreleased]heading above it does not interfere.PLAN.md
Version-map row plus a full slice section. It records what shipped per PR, what was deliberately not done (tag/release; no cross-stack version guard, with the reasoning), and — kept explicitly — the audit finding that was investigated, fixed, and then withdrawn when Chrome contradicted the jsdom evidence.
Exit criteria are ticked except the last, which reads:
CHANGELOG.md[1.0.11]; tagv1.0.11; release published. Paused for operator go-ahead.Unlike v1.0.8–v1.0.10 there is no design spec or plan doc — this began as a bug report mid-session, not a planned slice. The investigation lives in
docs/PROGRESS_LOG.md(2026-07-31) and the six PR bodies.Verification
Frontend
vitest84 passed /tscclean /eslintclean. Backendpytest -q361 passed, 72 skipped /ruffclean /uv lock --checkclean.After merging this
git tag v1.0.11 && git push origin v1.0.11firesrelease.yml, which extracts the section verified above and publishes the release. Prod already runs this code; the tag is a label, not a deploy.Note
/_/backend/healthwill still report1.0.10until this merges and redeploys — the six fixes shipped under the old version number, which is exactly the drift the guards now prevent going unnoticed.Vercelcheck is not this diffFlagging so it is not read as a code problem. It does not block merge — the PR is
MERGEABLE/UNSTABLE, i.e. a non-required check is red.Evidence:
9c8a06b, and an empty retrigger commit38ff586) failed identically:BUILD_FAILED/Resource provisioning failed,state: ERROR, ~1.2s, and zero build-log events —errorsOnlyreturns "No error/stderr/exit events in this build." It never reached a build step, so nothing in the repo was executed.target: null— preview deployments. Production is a separate target and is healthy: the last production deploy (ee885a8, merge of fix(frontend): cache the session server snapshot (2 more 'known noise' entries were real) #64) isREADY, and prod was verified live earlier today (site 200,/_/backend/health1.0.10db+cache up,/analyze/octocat200).target: production. Preview deploys have never succeeded here because they have never run.uv.lock's root version, and two markdown files. It cannot cause resource provisioning to fail.Retriggering was deliberate — it distinguishes a transient platform blip from a persistent config problem, and it came back persistent. That is why the branch carries an empty
chore: retrigger vercel previewcommit; it is kept rather than force-pushed away so the diagnostic is visible.Likely cause, not confirmed: the Preview environment has never been provisioned for this project. It is a multi-service deploy (
framework: services, Node + Python) backed by Marketplace resources (Neon, Upstash), and previews need their own environment/env-var scope. That is a Vercel project-settings matter on your account, not something fixable from the repo — so I stopped here rather than guessing at settings.