docs: migrate the changelog out of the line-8 header field into PROGRESS §7 - #66
Merged
Merged
Conversation
…ESS §7 The "Last updated" header field had accreted the entire update log into a single 37,590-byte line -- 25.8% of the file, 98.7% of it entry bodies. A header field is overwritten every step; a log is appended every step. Storing the second inside the first caused every symptom: unbounded growth, a lost date label, and a 106,630-byte diff to express PR #64's 6 insertions. Separates them by lifecycle. New append-only "## 7. Changelog" section, appended after §6 -- §1-§6 are NOT renumbered, since 32 §-references depend on them. All 17 entry bodies moved BYTE-IDENTICAL: nothing reflowed, re-wrapped, added or stripped, including each body's original (and in nine cases unbalanced) parentheses. The 2026-07-20 entry, absorbed undated into the head by PR #64, regains its date label; its bytes are unchanged. Preservation proof (sorted, NUL-joined sha256 of all 17 bodies): before 53e227aefee8d1e8a769d092c824345baaca6679419473f67d24bf930d0eb78b after 53e227aefee8d1e8a769d092c824345baaca6679419473f67d24bf930d0eb78b Entry count 17 -> 17; §7 body bytes 37,095. Lines 1-7 and 11-184 are byte-identical to main (region sha256 40f6d3cd...), so no register row, no §1-§6 content and no phase status changed. Register #17 stays OPEN. This RETIRES the Option C frozen-tail invariant by design: that hash existed only to police a boundary inside an unreviewable single line. The append-only rule replaces it -- a future update adds one ### block and git shows one added hunk with zero deletions, so no bespoke hash is needed. Also refreshes the three header fields, which were stale: Active branch named a deleted branch, Main tip named 3378dd8 (two merges behind c119f6b). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
tornidomaroc-web
added a commit
that referenced
this pull request
Jul 23, 2026
…te) (#67) vercel.json's `experimentalServices.ingestion` block was serving a LIVE DUPLICATE of the ingestion service at /_/ingestion — confirmed by a 200 from `GET https://tryknowflow.com/_/ingestion/health`. It was NOT vestigial-inert, and NOT stale April code: Vercel rebuilds `services/ingestion` from the deployed commit, so it runs the same current main.py as the real Railway service (INGESTION_SERVICE_URL = knowflow-production.up.railway.app). The duplicate is token-shared: INGESTION_TOKEN is a Vercel project env var the Next route already needs, so the same token that authorizes Next->Railway opens this copy's /convert and /embed. VOYAGE_API_KEY is set on Vercel, so a token-holder could burn Voyage credits and run arbitrary documents through MarkItDown here, bypassing every Next-route guard (auth, per-KB limit, enforceLimit, rate limits) — none of which live in the Python service. /health is unauthenticated and discloses provider/model/dimension. This removes ONLY the `ingestion` sub-key, keeping `frontend` exactly as-is, so the Next.js frontend keeps deploying. Logged as register #45 (OPEN). A distinct incident from B5b — the B5b row and PIVOT_PLAN.md:270 are deliberately untouched. MANDATORY sequencing (rotate LAST): (1) merge; (2) confirm production /_/ingestion/health -> 404, and DELETE the Vercel service in the dashboard if it does not (config removal may be necessary-but-insufficient); (3) THEN rotate INGESTION_TOKEN on Railway then Vercel. Rotating before teardown just re-exposes the fresh token on the shared-env duplicate. Preview must be verified before merge: frontend still serves + a real upload completes via Railway, and <preview>/_/ingestion/health -> 404. Header fields refreshed per the §7 policy merged in PR #66 (Active branch pointed at a deleted branch, Main tip was one merge stale). Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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.
Docs-only. Moves the update log out of the
Last updatedheader field into a new append-only## 7. Changelogsection, with every entry body preserved byte-identical.Why
A header field is overwritten every step; a log is appended every step. Line 8 stored the second inside the first, and that single root cause produced every symptom we hit: unbounded growth (head 2,380 → 3,518 → 6,112 chars over three docs PRs), the 2026-07-20 date label absorbed and lost, and PR #64 needing 106,630 bytes of diff to express 6 insertions and 4 deletions. Line 8 was 37,590 bytes — 25.8% of the file, 98.7% of it entry bodies.
Separating the two by lifecycle fixes all of it at once.
Preservation proof
All 17 entry bodies moved byte-identical — nothing reflowed, re-wrapped, added, or stripped, including each body's original (and in nine cases unbalanced) parentheses. Normalization was deliberately declined: it is exactly where silent corruption enters.
The paren-stripped digest was not used — bodies are not uniformly wrapped, so that transform is unsafe.
Scope — proven, not asserted
No register row, no §1–§6 content, no §5, no phase status, no code, no CI, no migration, no legal/refund copy. §1–§6 are NOT renumbered — 28 §-references in
PROGRESS.mdand 4 inPIVOT_PLAN.mddepend on them, so the new section is appended as §7 and cross-references are qualified as "PROGRESS §7" (the file already uses §7/§8/§10 to mean PIVOT_PLAN sections).The 2026-07-20 entry, absorbed undated into the head by PR #64, regains its date label; its bytes are unchanged.
This retires the Option C frozen-tail invariant — by design
That hash existed only to police a boundary inside an unreviewable single line. It is superseded, and this PR records the retirement explicitly rather than letting it lapse silently.
The new invariant, stated in §7's preamble: an update adds exactly one
### YYYY-MM-DD - <slug>block directly below the preamble and changes nothing else in §7 — sogit diffrenders one added hunk with zero deletions. Entries are immutable once landed; a correction is a new superseding entry, never an edit. No bespoke hash is needed going forward: the diff is the proof.Header fields refreshed
They were stale and self-contradicting:
Active branchnameddocs/progress-log-gate-hardening(deleted),Main tipnamed3378dd8(two merges behindc119f6b), and the old line carried a reminder that no longer matches the structure. All three now carry current, verified values.Checks
npm run typecheck→ exit 0.db-types: no SQL migration touched, so regenerated types are byte-identical.🤖 Generated with Claude Code