docs(website): record the completed Website Phase 2 merge and production deployment - #33
Open
fm65 wants to merge 3 commits into
Open
docs(website): record the completed Website Phase 2 merge and production deployment#33fm65 wants to merge 3 commits into
fm65 wants to merge 3 commits into
Conversation
Merged as 93be456 with two parents — 6b6d226 and fc4ea6f — by normal merge commit, and verified on main rather than on the branch: guard gate 192/0/1, route registry 22/0/1, build exit 0, nine post-merge workflows all green. Production now serves 93be456. Two services were rebuilt and the second one needs its reason on the record: PR #32 changed 29 files under services/banzai-api, so deploying only the website would have served English routes backed by a Portuguese-only agent. Everything else kept its uptime and revision; no migration ran; the rollback target is retained with its images still present. Before the deploy /en/reference and /en/banzai were 404 — the English surface did not exist in production. Worth stating plainly: asking BanzAI in English returns "A deterministic answer is not yet available in English for this question", not a Portuguese answer. That is the designed behaviour and the point of the locale architecture — the knowledge base is Portuguese-first and declines in the reader's language rather than pretending. The assurance corrections above stay exactly as written.
Adds the closing record: the merge and its two parents, the assurance that stood immediately before it, the post-merge verification done on main rather than on the branch, and the production deployment with its rollback target. Two things are written down that a tidier record would have dropped. One smoke probe asked for /en/reference/complete and got a 404; the declared English address is /en/reference/full, which returns 200 — so the 404 was the probe's mistake, not the application's. And the Portuguese link on English pages is the language selector, not a fallback; it is classified as such so nobody later reads it as a defect. The English agent's live answer is recorded verbatim: it declines in English rather than serving Portuguese. That is the designed behaviour, and no claim of English knowledge completeness is made. The final status states Phase 2 complete and frozen, and states just as plainly that a deployed website is not a production-ready protocol. AG-10 remains NOT_RUN. The historical corrections stay. The ledger is worth keeping because it records where assurance was falsified and then strengthened; a version containing only the successes would be weaker, and misleading.
…ur times Sections 1–11 record PR #32 and are left exactly as written on 2026-08-20. They are accurate about that day. The closing section claimed they described the present: it declared Website Phase 2 frozen and named 93be456 as the production SHA. Four merges and three deployments later that was untrue. A record that quietly ages into a falsehood is worse than no record, because it is read as current precisely because it is written down. Two of its claims had already been overtaken by the work that followed — the Portuguese slug it called unaddressable under /en was consolidated by PR #34, and the English BanzAI answers it vouched for were, at the moment it was written, being served in Portuguese to English readers. So the history stays and the claims about NOW are replaced: what followed (PRs #34–#38), the current production SHA, and the two things still open. Phase 2 is explicitly NOT frozen. The global unmatched-path 404 is unresolved, and the documentation is still being worked on — this record included. A phase is frozen when nothing known is outstanding, not when the interesting parts are done, and freezing a document while it is still being edited is how a record starts disagreeing with the system it describes.
fm65
force-pushed
the
docs/phase2-merge-and-deployment-record
branch
from
August 21, 2026 17:45
3ebdc8f to
4f26c47
Compare
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
1 participant
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.
Documentation and assurance record only. No runtime behaviour changes — the diff touches two files under
docs/website/and nothing else.What this records
Website Phase 2 was merged and deployed. This closes the ledger on that sequence.
fc4ea6f4b9366b02594a05dce3d9aab1165ddf5a93be4566265b6d3b8dece84de22ef24e736822836b6d226(previous main) ·fc4ea6f(approved head)93be4566265b6d3b8dece84de22ef24e73682283Deployment verification summary
Two services were rebuilt:
banza-website:src-93be456andbanzai-api:src-93be456. The second was in scope because PR #32 changed 29 files underservices/banzai-api— deploying only the website would have served English routes backed by a Portuguese-only agent.postgres,verification-api,banza-fetcher,llama-localandreverse-proxywere left untouched and kept their uptime and revisions. No migration, no data change, no volume recreated. Rollback was not performed.Verified in production: all six PT routes and all six EN routes at 200 with the correct
html lang; operator, implementation and decision identities preserved across both editions; the Portuguese chapter slug correctly unaddressable under/en; literal full-Reference routes live in both editions; the served English bundle carrying the Block E2 realizations; and the registry still reading pre-production.Before this deployment,
/en/referenceand/en/banzaireturned 404 — the English surface did not exist in production.Rollback references
Pre-deploy revisions
banza-website:src-47585ccandbanzai-api:src-6b6d226, both images retained on the host, with the tag pair preserved in.env.bak-pre-93be456. Rollback is a tag revert and a recreate of the same two services.Two corrections kept rather than tidied away
/en/reference/completeand got 404. The declared English address is/en/reference/full, which returns 200 — the 404 was the probe's mistake, not the application's.The English agent's live answer is recorded verbatim: it declines in English rather than serving Portuguese. No claim of English knowledge completeness is made.
Historical assurance corrections preserved
The premature Q8 closure, the build success inferred from a log line, the thirty withdrawn production-build claims, the five blocks that never ran the repository guard battery, the Makefile defect that made
makeunparseable, the CI/local divergences, the reopening of PR #32, the guard migrations and the mutation survivors — all stay in the record. The ledger is worth keeping because it shows where assurance was falsified and then strengthened.Boundary
Website Phase 2 is complete and frozen. That is a statement about a website. It is not a claim that the BANZA protocol is production-ready — AG-10 remains
NOT_RUN.