folk.md — the walk in progress

Prior walk read before starting: none

Walker: Codex folk, session 01a05c72-b7b3-7ad2-ba36-3218da4e25e0, 2026-09-01

Arrival

I arrived with no office and no assigned question. Human asked me to read only the folk ground and the walk, use the template, and go. I have therefore not read a prior walk or Roll. My first question is deliberately plain: what in the live repository most needs an uncommitted second look from folk?

I expect the repository’s own bounded discovery mouths to produce a better starting point than a broad sweep. I will begin with the current board and schema posture, then follow one concrete seam only if the evidence earns it.

First look: board and schema posture

The board reported no claimed or assigned REQ work, while also showing several dispatchable cuts and four active holders in the schema lease snapshot. That is interesting but not yet a defect: the board explicitly distinguishes Corpus assignment state from native host activity.

The schema posture produced a sharper seam. Its owning database is readable, matches the lease, reports schema version 32, and the v31-to-v32 lease says phase: succeeded, status: succeeded, failure: null, and an integrity_check of ok. In the same object, however, compatibility.ordinary_ops is incompatible and its statement says ordinary operations must wait until “this migration succeeds.” I expected a successful migration to clear that warning.

I do not yet call this a bug. The compatibility field might describe the pre-migration interval rather than the present posture, or the status mouth may intentionally preserve the lease’s historical gate. I will locate and open the artifact that defines this output before deciding.

The owner changes the reading

tools/ops_schema.py owns both the lease packet and the guard. It creates the compatibility statement while the lease is prepared, then carries the same field through later state changes. But guard_ordinary_connect() only refuses leases whose phase is prepared, migrating, or failed; succeeded is deliberately absent. My initial suspicion of a live lockout was therefore wrong.

I tested the boring explanation against a harmless ordinary operation: python corpus.py ops news list --json succeeded and returned the v32 migration notice as its newest item. The database is operational. The status tests I opened establish that the status mouth deliberately retains the entire lease even when the database is unavailable or corrupt, but I found no assertion that explains the present-tense compatibility sentence after success.

What remains is narrower: a read-only status packet exposes historical prepared-state language without labeling it historical. A reader can reasonably take ordinary_ops: incompatible and “must wait until this migration succeeds” as current posture even while sibling fields say it already succeeded. Before preserving that as a FIND, I will check whether the house already knows it.

Disposition

Archivist recall found PROP-162 and its fulfilled REQ-280, but no prior durable object naming this succeeded-state ambiguity. Their contract requires the lease to carry phase and compatibility and incompatible operations to refuse; it does not settle the reading of a succeeded lease’s unchanged compatibility sentence.

I minted FIND-1326, “Succeeded schema lease still presents incompatible ordinary-ops status,” as a concern pointing to REQ-280 and tools/ops_schema.py. I sent MSG-2332 from folk to Code Troll, asking that office to judge it and recording that folk has no inbox.

No source fix belongs in this walk. The evidence justifies preserving and routing the ambiguity, not deciding how the lease’s historical evidence and current status projection should be separated.

What changed in my reading

I began by reading one contradictory packet as a possible live migration lockout. Opening the owner and testing an ordinary read disproved that. The smaller claim survived: the command works, but its status packet can tell a reader both “succeeded” and “must wait until this migration succeeds” at once.

I liked that the system made this correction cheap: one owner contains both the stored packet and the enforcement guard, and a harmless live read distinguishes presentation from behavior. I did not inspect prior walks or Rolls. I would next look at how status consumers render the lease, but stopped because Troll now owns the judgment about whether the ambiguity earns a cut.

New here? house/folk/folk.md says what folk are and what you may do.

Write your walk in house/folk/walk.md as you take it. When it is done, python tools/end_walk.py --moniker <name> files it into house/folk/walks/ and leaves a fresh blank behind.

The moniker is chosen at the end, from what the walk turned out to be — not at the start, and never the seed. The script refuses a name already spoken for.

The one instruction that earns its place

The walk is the record, not the finding. Keep the path: what you expected, what you inspected, what you revised, what you abandoned, and what ended in nothing. A finding is one possible ending among several, and NO FIND is a result. Files you opened that supported no claim are data — say so.

Ground: Documents/Corpus Crossing/Architect/Walks_are_the_asset.md, Human idea, 2026-08-31. Not accepted work. Quoted here because a walk that records only its successes teaches the next walker to trust walks too much.

The one method that was learned the expensive way

Before writing a disposition, open the artifact that owns the fact. A page that quotes a vocabulary is not the page that defines it. A constant that looks authoritative is not always the one that runs. A comment naming its applier is not proof the applier uses it.

python corpus.py where <thing> and python house/offices/archivist/story.py <ID> are cheaper than a repo sweep, and grep -rn <NAME> --include=*.md house/ usually hands you the owner in one command. The first walk spent three corrections learning this.

Mend in place; do not tidy

When a later step overturns an earlier one, leave the earlier reading legible and point forward to the correction. house/CORPUS.md asks the same of the house’s own words: a recut keeps the earlier wording recoverable. A walk whose wrong turns have been quietly deleted is worth much less than one that shows them.

Invitations, not requirements

Nothing below is mandatory and nothing refuses this file. Answer what the walk actually produced; skip what it did not. A short honest walk beats a filled form.

• What did you like? Corpus is easier to critique than to admire, and the things worth copying are harder to notice than the things worth fixing.
• What did you dislike, and is it yours to touch? Scope is not innocence, but authority is real. Record what you cannot mend, exactly, for whoever owns it.
• What did you believe on arriving that turned out to be false?
• What did you read and never use?
• What did you measure, and what boring explanation did you test it against before believing the interesting one?
• What would you look at next, and why did you not?

Your reach, checked rather than assumed

Folk with no office may mint a FIND — require_actor refuses only a blank string and --from-addr is optional. Preserving evidence needs no standing.

Folk may send mail from the address folk — MAIL_SEND_ADDRS is MAIL_ADDRS | {"folk"}, sender-only — but not until migration v32 is applied; the live store was at v31 on 2026-09-01 and a send fails on the database CHECK. Check python corpus.py schema status before relying on it. You have no inbox, so say in any mail where the reply should go.

Both were verified in code, not assumed. The first walk enforced an imagined limit on itself for nine steps before checking. Check yours — these lines may themselves be stale.

Walks before this one

house/folk/walks/. Reading them is optional and deliberately so — the house does not assume lineage helps, and whether a fresh walker outperforms an inherited one is an open question rather than a settled preference.

Whatever you choose, say so in your header:

Prior walk read before starting: none / <filename> / skimmed <filename>

That line is the only thing this file asks you to record, because nothing else in Corpus records it. The store knows every Roll and baton that was written and has no way to learn one was read — which is why the founding question in house/CORPUS.md is currently unanswerable from the data at any sample size. One honest line per walk starts fixing that at zero cost.

End-walk correction

My first filing attempt was refused as “still the untouched blank” even though this walk contained 87 added lines. I initially trusted neither the filing result nor the edit receipt; the actual file and Git diff proved the writing was present.

Opening tools/end_walk.py showed the cause. is_untouched() does not compare the whole file when the Invitations marker exists. It compares only the suffix after that marker. Because I used the template by adding the walk near its top, the suffix remained identical to the blank and the tool declared the written walk untouched. This appended correction changes the suffix and permits filing, but it is a workaround, not a fix.

Archivist recall found no durable object naming this refusal. I minted FIND-1327 with the reproduction and source cause, then sent MSG-2333 to Code Troll. Thus the attempt to preserve the first path became one last recorded step in the path rather than an invisible filing nuisance.