Timeline

The verified login — never the U card — becomes the per-request X-Zit-Protect the --fronted child enforces: the globs this pusher does not own, comma-separated as zit's glob lists are.

Sent on EVERY request, empty when nothing is refused. zit#151 reads an absent header as no rule, so absence is exactly what a forgotten code path would produce; here it cannot happen, and a test proves it against a fake child. The proxy builds a fresh request, so a client's header with that name never reaches the child. A rule source that cannot answer fails the push closed.

End to end with a real zit: a non-owner's push to trunk is refused with the branch named; the owner's identical push lands. closed check-in: daa9fc84b5 user: dmestas tags: protect-2

The first test called DeleteRepo, which drops the repo row and leaves per-repository state to PurgeRepo — the cascade the rule was added to. Committed red because the run gating it used a regex that matched no test; caught by the suite. closed check-in: f30535d269 user: dmestas tags: protect-1

Forge policy beside repo_caps: a repository names protected branches (name or glob) and their owners. No trace in the repository; edited under 'a'; empty by default so an imported store behaves as it did.

MayJoin answers may-this-account-change-this-branch's-membership. Every matching rule applies, so a glob and a narrower name on one branch can only narrow. Refused lists the globs an account does not own — the per-request rule the sync gate will hand its child. A store that cannot answer says no: silence is not consent. check-in: 70d043b2e7 user: dmestas tags: protect-1

Three amendments from review, now that zit#151 has shipped.

The fold's DAG-based reading applied only to protected targets, so adding or deleting a protection row re-judged every landing on that branch — the thing Disposability forbids. It is now unconditional: a DAG fact is the same fact under any policy. The merge is identified structurally (non-primary parent on the proposed branch, bounded by the open date), not by tip ancestry, which breaks for a branch merged and then continued.

zit#151 shipped with an absent header meaning no rule. Correct for a bare server; behind a front it means a gate bug silently disables protection. The RFC now records that and places three obligations on the gate: always set the header, strip the inbound one, prove both.

Test matrix gains the missing rows; What-this-is-not records the supersede interaction; build order marks phase 0 done. closed check-in: 2eff0c5d61 user: dmestas tags: rfc-0007-review

The timeline printed check-in comments as escaped text, so fossil's own bracket links showed as markup. commentHTML already existed and was wired to the check-in page only; the timeline now uses it for the lead line and each paragraph. Flat rows keep plain titles — theirs are drawn inside a link already, and an anchor cannot nest.

Surveying every link form fossil writes turned up three quarry HAS a page for and dropped anyway: /info, /artifact and /whatis (21 citations across the corpus) reach the same page a bare [hash] does, and /tktview reaches the ticket. A hex tail is required, so /info/2020-06-02T17:38z keeps its documented fate.

An unlabelled route printed its own path as the link text — markup leaking into prose, the one thing this renderer must not do. Those now read as prose.

/forumpost still aims at the forum index on purpose: measured against the fossil clone, 303 of 304 cited forum hashes are not present locally, so a deep link would 404. check-in: 51930149be user: dmestas tags: trunk

zit landing comment grew --reply-to, so a parented remark no longer has to detour through forum reply. Both cases go through LandingSay, which means the landing-specific error handling below — conflict and refusal decoding — now covers every remark rather than half of them.

The same-thread check stays. zit refuses an out-of-thread target too, but here it is a capability boundary: quarry does not delegate its permission model to an upstream refusal.

Artifact cards verified unchanged: G=root, I=parent, identical to what the forum-reply path produced. check-in: 3886890ee7 user: dmestas tags: trunk

zit landing comment grew --reply-to, so a parented remark no longer has to detour through forum reply. Both cases go through LandingSay, which means the landing-specific error handling below — conflict and refusal decoding — now covers every remark rather than half of them.

The same-thread check stays. zit refuses an out-of-thread target too, but here it is a capability boundary: quarry does not delegate its permission model to an upstream refusal.

Verified the artifact cards are unchanged: G=root, I=parent, identical to what the forum-reply path produced. closed check-in: bda97ce3df user: dmestas tags: protected-branches

Two things the ops history surfaced.

GET /{$} serves two pages: the fleet for anonymous readers and the dashboard for signed-in ones. The census fix landed earlier addressed the fleet listing, so the spike a signed-in reader sees was never touched — the route pattern hid two different pages, which is the thing the drilldown exists to expose.

Measured cold across this fleet, EventKinds is 610ms of that page: a full covering-index scan of every artifact, per repository, for numbers that only move when a fold does. Memoised beside the other two, invalidated with them. TicketCounts measured 110ms and was left alone.

Asset requests are file serving, not renders. The browser asks for a sourcemap nobody ships, so /assets/datastar.js.map fell to the catch-all and filed a 404 against route '/' several times per page view. closed check-in: 9bc994bada user: dmestas tags: ops-noise

A check-in joins a protected branch only by an owner's hand; accepting a landing on it follows from that rather than being a second rule. Policy lives in OLTP beside caps, is evaluated at the xfer gate and the accept op, and writes nothing to the repository — fossil compatibility is a normative section, not a hope. The one zit change is drafted in Appendix A. check-in: d4cf4acf26 user: dmestas tags: protected-branches

Recent renders showed the route pattern, so a dozen rows all read GET /r/{repo}/timeline and none could say which repository was slow. The URL is now recorded and shown, with the route beside it as the link to its drilldown.

Two bugs found by clicking through rather than by testing the parts:

queryesc double-encoded every URL it touched, because html/template already escapes a value in query context. The routes panel linked to its own drilldown with %252F for a slash, so every link 500'd. Six call sites, all wrong; the function is gone.

The days control I added with the trend forwarded an empty parameter, and a numeric field with a default takes it when the key is MISSING and refuses when it is present and empty.

Routes panel gains a filter and a sort; renders gain a deeper-history page reading the store rather than the ring. closed check-in: 2d033f106e user: dmestas tags: ops-paths

Filed upstream: landing comment sets G and I to the record root, so it cannot aim a reply. The forum-reply route stays until that lands; quarry ticket 6f4c8579f0b5 tracks collapsing the fork. check-in: b459791bbd user: dmestas tags: trunk

At phone width the brand and version already retire, but the timing string alone still outran the viewport — and being flex:none it printed over the footer links rather than giving way. The per-store breakdown now retires at the same step the brand does; the total, which is what the footer is for, survives.

The collapse test pinned the whole media rule, so adding a part to a step read as a regression. It now matches the breakpoint and the parts within it, and asserts the total is never itself hidden. check-in: d7ff96b534 user: dmestas tags: trunk

t-row is a three-column grid. The reply badge made the state mark a fourth child, which wrapped to an implicit row under the glyph — the accepted pill dropped onto a line of its own. Both now sit in a t-tail cell, so neither can displace the other. check-in: f876bfc649 user: dmestas tags: trunk

The landing list carries a reply badge, the same .t-conv/#i-comment the ticket list uses; the count excludes state transitions, which are events rather than things anyone said.

The discussion renders as the thread it is: the forum's own forumPostRow, participant spectrum, hue edge, indentation and 'replying to' attribution. The threading walk moved out of the forum handler into threadShape so the two pages cannot drift.

A remark aimed at a post goes out via 'zit forum reply' — a landing thread is a forum thread of the same artifact kind, and that is the one verb that can point the I-card at something other than the opener. The target is checked against the record's own thread first.

Merges the superseded/CI work that landed on trunk meanwhile. check-in: 5815a2a7d8 user: dmestas tags: trunk

The ticket asked to decide the shape — forum reply or tag — before wiring the display. Neither is needed: a verdict is already a tag on a check-in, quarry already folds and reads them, and a landing proposes a branch whose tip is a check-in.

Better on its own terms too. The verdict stays attached to what was actually tested rather than to a discussion record, keeps the zit#127 invariant with no new vocabulary, and a retargeted or reopened landing inherits the right answer without anyone copying it across.

Read at render, never stored, so it cannot go stale against the branch it describes. No run leaves it empty, which reads as 'nothing has run' rather than as bad news. closed check-in: 1305bb9374 user: dmestas tags: landings-batch

zit#127 left this as 'probably yes, refused by name on the second' and neither side enforced it, so two threads naming one branch produced two open landings with nothing saying which accept should honour.

Both halves, because refusing is not enough: two peers can each open one in separate clones and both are valid artifacts when they meet. landing.open refuses by name; the fold picks the newest root as current and marks the rest, recomputed each fold so a record revives if the one that displaced it is settled.

Settled landings never take part — a later proposal for the same branch is a new proposal, not a correction of a finished one. Nothing is deleted; a record somebody argued in is not noise. check-in: c2930a1351 user: dmestas tags: landings-batch

The page listed the branch through the timeline, which orders by (date DESC, hash DESC). Two check-ins in the same second tie on date and then order by hash, which has nothing to do with which is the parent. Commits land back-to-back here routinely.

zit hit this in landing show and its fix is the one to inherit: the verb owns no ancestry ordering of its own. A recursive walk from the branch tip, ordered by longest path back, stopping where the branch diverges from its target.

The test commits three times in one second with hashes whose order is the reverse of ancestry — the old sort gets it exactly backwards and looks plausible doing it. check-in: 21fde3240d user: dmestas tags: landings-batch

The stream carried the filter it was opened with, so every later tick repainted the reader's page with a view they had left. That is not a bug that gets fixed once — it shipped, was fixed this morning, and would come back the next time a default moved, because the shape makes it possible.

The fleet page was rebuilt around a revision number for this reason. The timeline now follows: the signal says THAT the repository changed, the client re-requests the listing and sends its own controls with it. Nothing can capture a filter and outlive it.

A fragment is delivered as SSE but is a render, so it is marked and still measured — otherwise the refresh path would have been the one route the ops panel could not see. closed check-in: 0f1c202c58 user: dmestas tags: tl-rev

An accepted landing showed an empty Changes section. Not an error — the right answer to a question nobody was asking.

While a landing is OPEN the useful base is the target's current tip: what would merging this change now. ForkPoint's comment says as much and calls the distinction deliberate. But once the record is SETTLED the branch is already contained in the target, so that question has a degenerate answer, and the only reading left is historical: what did this branch do. That is the fork point.

Base is chosen by state now. On the record that prompted this, the diff goes from 0 files to 12.

Second defect in the same block: the else branch says it exists so an empty Changes section never reads as 'no changes', but it only fires when the invoke FAILS. A call that succeeded and found nothing fell through to the success path and rendered exactly that blank. It now says so, naming both check-ins. check-in: 469dbab422 user: dmestas tags: trunk

The store recorded renders and nothing read them. The panels are one process's memory, so the page could say how fast a route is now and never whether it is worse than it was — which is the question after a deploy.

The drilldown gains a per-day table from the store: p50, p95, max. Nearest-rank percentiles, matching how the snapshot computes them, so two numbers on one page both called p95 agree.

Empty for no traffic and empty for history-off are different answers and the page gives the right one. closed check-in: a0fa952495 user: dmestas tags: landing-merge

settled_by names the reply that decided the state, not the commit, so this was assumed to need an upstream change. It does not: a merge check-in lists its primary parent first and the branches it merged after, so ord > 0 is the branch tip that landed, and the landing knows which branch it proposed. Structural, not a text or time heuristic. Resolves 18 of 18 accepted landings in this store.

Bounded by when the landing OPENED, not when it was accepted: the merge lands before the artifact recording it is written.

The landing page says what it landed as; a merge row on the timeline names the proposal and who approved it. Decorated, not collapsed — a merge is a real DAG node and hiding it would leave the graph drawing edges to a row the timeline does not show. check-in: 06475f5aee user: dmestas tags: landing-merge

Landings are built on forum artifacts, so the forum trigger filed every comment and verdict as kind 'f' with a 'Forum: ' prefix — rows reading 'Forum: zit-landing-state: accepted Accepted. The forge now tells y'. quarry had already decided these are not forum content; the timeline was the surface that missed it.

Verdicts are kind 'l' and appear in a mixed timeline because they change the target branch. Comments are 'lc' and appear only under the new y=l. Both link to the landing rather than the post.

Classified in the fold, not the trigger: the trigger fires before the landing row exists, since the root post is what it is derived from. Backfilled for stores folded before this. closed check-in: 5d398dd22e user: dmestas tags: landing-timeline

SQL has no timing category of its own and cannot easily get one: the sqlite driver builds its connector through an unexported constructor, so there is nothing to wrap. The panel's honest answer is subtraction, and subtraction the reader does in their head is not an answer.

'rest' is now a column, the lede says what the ops-minus-zit gap contains and why SQL is not split out. closed check-in: 0d65af656c user: dmestas tags: fleet-census

The live panels read in-memory rings, so a forge whose store failed to open looked exactly like a healthy one. Sink.Err() existed and nothing asked it. The page now distinguishes three states: off, broken, and recording to a named path.

Retention was 'append for ever', which is a default nobody was asked about. --analytics-keep sets the window, 14d by default, 0 keeps everything. Pruned at startup and daily. check-in: e2b74749b4 user: dmestas tags: fleet-census

Marks were stored second-granular like index post dates, so opening a thread in the same second its newest post landed left the thread the reader was looking at unread. Marks now carry a fractional part, which makes the two orderable: a post from the view's own second was in the page and reads as seen; any later second re-brightens.

Adds a harness test that walks the whole loop, including the part worth pinning — forum.get does not mark read, only forum.read does. check-in: c7bf7c08f0 user: dmestas tags: trunk

The fleet listing called Counts, the per-section census the repository nav needs: eight aggregates per store, of which a fleet row displays two. A fold invalidates the memo, so during indexing every row went cold at once.

Cold, on tcl (668MB, 42k check-ins): 230ms of census per repository against 80ms for the two numbers. Contributors now reads the maintained contributor table rather than a DISTINCT scan over every event — verified identical across all 25 demo indexes. check-in: c5d8786875 user: dmestas tags: fleet-census

Dimming keyed on a 30-day window meant a quiet forum rendered almost entirely grey. Read-state replaces it: forum_read stores when an account last viewed a thread, and a thread is read only while its newest post is no newer than that view — so a reply re-brightens it with no flag to clear. Anonymous readers have no read-state and see every row at full ink.

Marking read is its own op, not a side effect of forum.get, so crawlers and API clients cannot spend a reader's unread state. Titles now take the accent colour on hover (gated on hover: hover) and on :active, so touch keeps the affordance. check-in: c8a93fda64 user: dmestas tags: trunk

dev.local.mk said nothing about what it held, so the only way to learn what `make dev` needed was to read someone's copy — and there was no copy to read, because it is not committed.

.env.local now holds one named key per setting instead of a single 1,697-character DEV_ARGS line, and the Makefile composes the flags. A key left empty is omitted from the command line rather than passed as an empty string, which the server would read as a deliberate value. Corpus repositories are named once each and their paths derived, rather than --repo name=path repeated twenty-three times.

.env.example is committed and documents every key, including which two are secrets and which of --data and --oltp survives a rebuild.

dev.local.mk is still included, so an existing checkout keeps working, and both names are ignored. Verified equivalent: the old file and the new one produce the same 8 flags and the same 23 repositories.

`make dev-args` prints the composed flags without starting anything. check-in: 6be29eb1b4 user: dmestas tags: trunk

The check-ins default lived only in the page handler, so a reader on the default timeline had an empty query string — and the live stream opened with it asked for no filter at all. The first tick after a landing replaced their check-ins with everything.

Both the page and the stream now resolve through timelineQuery. closed check-in: 550f9601a2 user: dmestas tags: tl-filter

Three files written in the same minute on 15 Aug and committed by accident. g1.json is a wiki API response for a page titled 'evil/traversal', g2.html the rendered edit page for it, g3.json a failed call that returned 'no such endpoint'. curl -o output, named g1 through g3, left in the repository root where they read as though they belong to the project.

Nothing references them: no Go file, no Makefile, no Dockerfile. They shipped with every clone and told a reader nothing except that someone was probing path traversal in wiki page names that evening. check-in: 2946cb4429 user: dmestas tags: trunk

Repo was read with req.PathValue in the outermost middleware, where the router has not set it — path values live on the request the mux passes DOWN, a copy that middleware never sees. Same shape as the route-pattern bug, and it went unnoticed longer because an empty string looks like 'no repository' rather than like a failure.

Every render recorded until now carried an empty repo: 61 of 61 rows in the analytics store, on a fleet where repository size is the dominant cost of almost everything. The drilldown's by-repository table showed a single '(none)' row, which is what surfaced it.

Read from the path instead, unescaping as the router would. closed check-in: 059fe0bdde user: dmestas tags: ops-drill

/fleet/ops linked OUT to /fleet seven times and nothing anywhere linked IN. The page was live, gated, and reachable only by typing the URL.

Second surface to ship that way after the notes feed, so it gets a test rather than a promise to remember — both directions, so an admin is never stranded on either.

The link goes in the summary strip that already carries the fleet's counts and the error badge, which is where somebody reading health already is. /fleet answers 'are my repositories healthy'; /fleet/ops answers 'is the forge healthy'. check-in: 3314daeff6 user: dmestas tags: ops-drill

The panel finds a slow route; this says why. Two things the roll-up cannot show.

WHICH REPOSITORY. A route pattern folds pikchr and tcl into one line, and repository size is the dominant cost on this fleet — GET /r/{repo} at 420ms could be either, and the two differ by orders of magnitude.

WHICH CALLS. Each recent request is listed with the store calls it made, in the order it made them, and what they cost together. A request with no calls listed spent its time somewhere else, which is itself the answer when the store is not to blame.

Reads the same rings the panels read, so a request that has aged out simply is not there. That is the honest limit of a snapshot: this answers what a slow request just did, not what happened yesterday. check-in: bb6ec6b896 user: dmestas tags: ops-drill

--data is derived and disposable; the OLTP is truth and is not. That is only worth stating if something checks it.

Wiping the derived directory must keep accounts and capability grants, and the converse test keeps the old interleaved layout honest: without the flag the same wipe destroys them, which is exactly what the split exists to escape.

Confirmed against the real binary too: wiping a 4.3M data directory leaves the forge serving 200 with its file listing intact and the index rebuilt from the stores, and the account still there. check-in: 6c2ed45467 user: dmestas tags: trunk

The panel could find a slow route and never say why: the render list and the subprocess list were two independent tables, so 'GET /search took 1132ms' and 'zit artifact ran 499 times' could not be connected even when one caused the other.

Every request is now tagged at the outermost middleware, and every store call records the tag. Work with no request behind it — ingest rounds, warm passes, the doc indexer — records the empty string, which is itself the useful distinction: store load with nothing to blame is background, and telling the two apart is most of what the subprocess panel is for.

Also fixes a silent hole of the same shape as the route-pattern bug: Repo was read with req.PathValue in the outermost middleware, where the router has not set it — the values live on the request the mux passes DOWN. Every render recorded until now carried an empty repo, 61 of 61 rows in the analytics store, which made the numbers unattributable on a fleet where repository size is the dominant cost. Read from the path instead. check-in: bc35cc0c45 user: dmestas tags: ops-drill

The fleet recorded GET /r/{repo}/timeline.sse at a p95 of 435 SECONDS. That is not a slow render, it is a connection somebody kept open for seven minutes — chat, the timeline and the ops panel all hold one for as long as the reader keeps the tab.

Two consequences, the second worse than the first. The slowest-routes panel was headed by four streams, burying GET /{$} at 1198ms against a 13ms median — the one real finding on the page. And every stream crosses the render budget by design, so the first-crossing alert fired on connections that were working perfectly: the muted-channel failure that rule exists to prevent, defeated from inside the same feature.

Detected from the response, not the path. A handler that streams says so in its Content-Type; a rule matching '.sse' would miss the next streaming route added under another name. Prefix-matched, so a charset does not defeat it.

Found by the panel on its first look at real traffic, which is the argument for having built it. closed check-in: cf9a277e13 user: dmestas tags: ops-streams

--data holds two things that behave nothing alike. Per-repository indexes, built archives and the event store are DERIVED — rebuildable from the stores (0001 5), and therefore private to one node. oltp.db is not: accounts, capability grants, webhooks, praise, mirrors, saved views and CI runs are forge-local truth (0001 8), derivable from nothing.

Interleaved in one directory they could not be deployed differently, so two nodes could not have their own fast local index without also having two account databases that disagree. 256KB of the 4.5GB was the whole obstacle to running more than one node.

--oltp defaults to <data>/oltp.db, so a single-node deployment is unchanged. Every command that opens the OLTP takes it.

Verified: node A creates an account, node B with its own --data and the shared --oltp sees it; node B without the flag reports no accounts, which is the divergence this removes. Both nodes serve at once, each with its own index. check-in: 308751929f user: dmestas tags: trunk