Release 0.79.0 — the walk knows what day it is

[JimmyWesley]

Release 0.79.0 — the walk knows what day it is

One spec version, v0.79, and the package moves 0.78.0 → 0.79.0. It comes
from one screenshot: an operator asked a walk for the two screenshots I
uploaded today, on a 1,879-node forest that held exactly two media
nodes, and got told the product is not a place for personal files.

1  coverage                    1879 node(s)   ← two media nodes, range ending today
2  look   _index                  5 child(ren)
3  scan   _index                  0 node(s)   ← a flat scan with a filter the record could not show
4  sniff  terms=media             4 result(s) ← the WORD "media", in four task documents
→  "Não consigo trazer os prints… Este sistema não é um repositório de fotos."

Nothing was missing on the wire. since/until/date_field have been on
locate, sniff and scan since v0.52; type_filter, filter: {type}
and recursive existed; the loop forwards the model's arguments verbatim.
Three things were missing where the model reads: the menu named none of
those parameters, calendar was not on the whitelist, and no prompt said
what day it was. A model holding every window parameter there is can
write since and has nothing to write in it.

What changed

The menu names what the tools take (J.10.5). v0.67's rule about tools
— a tool the model is never told about is a tool the whitelist did not
admit — now covers arguments. Every searching call's window and filter
parameters are named, scan is told that a flat scan of the root lists
branches and that recursive walks the subtree, and two prompt rules join
the two of v0.67: a period in the question is a window resolved from the
stated date, and a kind of node is found by its filter, never by a sniff
for the type's name.

The walk has a clock (J.10.5 rule 3, J.10.7). The prompt states the
host's date, read off date.today(), the same clock that stamps created
and updated on every node the host writes, so "today" in the question
and "today" in the passports are one day. The date enters the walk's
store key on HEAD's terms, so a hunt asked on two days is two hunts and a
walk stored yesterday is not served today. Only the walk's: the sweep's
retrieval is the caller's, its bound is already stated, and a date in its
key would expire every stored answer nightly for nothing.

calendar joins the whitelist (C.13.3). For the reason coverage
did: counts by period, no bodies, every number the policy's own — the one
read that turns "today" into a window instead of a guess. The caller's
bound is forced onto it as onto the searching calls, so the map the model
sees is the map of what it may reach.

The caller's window still wins (C.13.1 rule 7). It lands last on
every searching call and on calendar, so a model-authored since is
replaced, not merged, and the prompt says so. The record shows the bound
normalised (2020 arrives as 2020-01-01), the two dates the search
actually used.

A hop names the argument that decided it. The record carried query,
terms, scope, parent_id, k — and none of filter, type_filter,
since, until, date_field, recursive, granularity, the arguments
that decide whether a listing is empty. Hop 3 above is why: scan _index → 0 read as an empty root. J.10.5 already required "the arguments
the model chose"; this is the record catching up with its own rule. A
calendar hop reports {buckets: n}; objects render as compact JSON on
the console.

The question has a period on the console (new J.5.19). Two date
inputs beside the question, sent as C.13.1's own parameters only when
set; read from the address beside q (a shared link asks the same bounded
question) and never a browser preference — a window remembered from
yesterday is v0.76's lesson one console over. The answer is labelled by
the response's window echo, never by the inputs; the history badges a
bounded run and restoring one restores its window.

The MCP surface is taught the same filter. The walk's hops is not
on the MCP answer tool, so the prompt changes never reach an MCP client
— but the walk's failure does: an agent asked for the pictures that sniffs
for the word "media" gets four task documents. The wire table and C.6b's
signature carried type_filter on sniff; the served tool alone omitted
it, and no description named it. Now the served locate, sniff and
scan descriptions and the generated skill say that a kind of node is a
filter, never a search for the type's name.

Found on the way

• consult_walk_store is a closure that had never imported inference;
  a bare name there was a 400 (answer failed: name 'inference' is not defined) on every walk. Caught by the store suite before commit.
• The suite's addopts = "-q" plus a second -q on the command line
  hides pytest's summary line entirely. Count the dots, or drop the flag.

Known gaps, stated rather than discovered

• A date input cannot display a coarse bound carried by a link
  (?since=2026-08): it is sent as it is, the engine expands it, the
  badge labels the answer, and the console deliberately does not
  re-expand it — a second expansion is a second reading of C.13.1.
• Whether a real model uses the window is F.5's business, measured
  offline; F.173 asserts the harness (what is named, what is forwarded,
  what is recorded, what is keyed).
• F.169 (the v0.75 curator on bench/questions-locate-v1.json) is still
  not measured.

For existing callers

• Every stored walk misses once after the upgrade (the key gained the
  date). Sweeps are served exactly as before.
• A pre-v0.79 hop record has none of the new argument fields; read the
  absent field as not set, never inferred from out.
• A caller's since/until on a walk now also bounds calendar and
  overrides anything the model sends on the same call.

Acceptance

F.173. Full suite green locally (1687 passed, 6 skipped, Python 3.12) and running in CI on this PR;
python -m build + twine check passed.