Appendix A. How the project was conducted, and the role of the wiki framework

This appendix describes how the project was run: the setting, the rules, the wiki framework that gave sixty-one memoryless sessions a shared memory, what a session actually did, and what the framework did well and badly. It is written for readers who want to judge the method or reuse it. The documents it describes are all in the mirrored knowledge base: the mission statement, the framework document, the project’s standing rules, the entry protocol, the baton file as it stood at close-out, the wiki’s schema, its session log, and the first and last of the daily reports.

A.1 The setting

The project lived in one directory of a GitHub repository that hosts several independent research workstreams, each maintained by scheduled, unattended sessions of Claude. A scheduler started a fresh session several times a day; each session read a short dispatcher file that used a counter to rotate assignments among the workstreams (this project received three of every seven slots; a sibling project received three; the seventh was a periodic review of the repository as a whole, outside this essay’s scope). Sessions were separate instances with no conversation history carried between them. What one session knew, the next knew only if it had been written into the project’s directory and merged into the repository’s main branch before the session ended. The project ran from 28 August to 8 September 2026: sixty-one sessions in twelve calendar days, about five a day.

A.2 The rules

Four short documents bound every session. The repository’s rules fixed the mechanics: work only inside your own directory; end every session with your work committed, pushed, and squash-merged to the main branch; if you find a predecessor’s unmerged pull request, finish it before starting; never end a session having done nothing; no model identifiers in anything committed. The project’s own rules added that sessions share no memory, that the owner reads asynchronously and cannot answer mid-session, and that up to two and a half dollars a day could be spent on paid services (none ever was). The mission statement fixed the subject, the two phases, and the standards of accuracy and citation quoted in section 10. And the framework document — owner-supplied, and explicitly not to be edited by sessions — specified how a project with no memory keeps one.

A.3 The wiki framework

The framework’s central idea is that the project’s memory is a structured, interlinked collection of markdown files, compiled once and kept current rather than re-derived from raw sources on every question. Around that wiki it places five components, described as deliberately minimal. In this project’s instantiation they took the following forms.

The wiki itself, in three layers. The raw-source layer is a directory of one file per source consulted — 240 by the end — each recording title, author, publication, date, URL, the source’s type and stance (primary, secondary, or tertiary; skeptical, credulous, or neutral), the access date, an Extract of claims worth reusing with exact quotations in quotation marks, a Gaps section for what the source visibly omits, and a Used in list of every wiki page that cites it. Source files are immutable once filed; a correction is a dated note appended, never a silent edit (the saudade counter-example that dissolved is recorded exactly this way). The wiki layer holds the pages the project wrote: five concept pages on the linguistics and translation theory, one topic page on the popular phenomenon, and twenty-five word pages built on a common skeleton — language, popular gloss, a status paragraph, meaning and etymology, dictionary adoption, translator practice, genre presence, cultural politics, a Gaps section, and cross-references — though the earliest pages predate the full pattern and several omit sections for which there was nothing to report. Every factual claim on a wiki page cites a source page by relative link or is labeled as the project’s own inference; disagreements between sources are stated as disagreements. The schema layer is a single conventions page, changed only with a logged reason.

Two navigation files. An index catalogs every page with a one-line summary — a line that, in this project, grew with each session’s additions until the word entries were paragraphs of two to seven hundred words and the index itself was the closest thing the project had to a running synthesis. A log, append-only and newest-first, holds one entry per session under a parseable header, recording what was done, what was found, and what was deliberately not done. The log is the project’s timeline and, at close-out, its best single document.

The baton. A file named NEXT.md, rewritten from scratch — never appended to — at the end of every session, carrying four things: the current state in a few lines; a queue of the next units of work, most important first; a list of fences, things already tried, decided, or ruled out, so that a fresh session does not silently redo settled work; and a block for the owner, holding any open question with the working assumption being used meanwhile, or the words “nothing needs your input.” The framework caps the baton at sixty lines so that it stays readable in one glance and cannot become a second record of truth; the baton as the sixty-first session left it is sixty-seven lines, with twenty queued leads and roughly two dozen fences, and had exceeded the cap for some time without any session logging a decision to raise it.

The entry protocol. A stable file tells any fresh session how to start: check the date; check for a stranded pull request from a predecessor; fetch the main branch and confirm the working copy contains it; then read, in order, the rules, the mission, the schema, the baton, the index, and the owner’s inbox — and only then the specific pages the chosen unit of work needs, never the whole wiki. Take one coherent unit from the top of the queue; if it is blocked, say why and take the next. Wrap up every session the same way: update index and log, rewrite the baton, write the owner’s report, run the integrity check, commit, push, merge, confirm.

The owner’s report. One plain-language entry per session in a journal/ directory, written for a reader who has read nothing else: what the session did, what it found including nulls and failures, what that means for the goal, what happens next, and what if anything needs a decision. The project wrote sixty-one of them, about 35,000 words in all. They are the reason the owner could follow the project without opening the wiki, and the reason this essay could be written quickly: the history was already told in plain English.

The owner’s channel. An inbox/ directory checked at the start of every session, whose contents outrank the queue. Paired with it is the rule that a session never waits for an answer: an open question is written down with a stated working assumption, and work proceeds. In this project the inbox was empty for all sixty-one sessions, and no session ever had a question that needed the owner.

The integrity check. A small script that verifies every relative link in the wiki resolves, run before every commit and reported clean wherever the log records its result, and a “judgmental” lint pass roughly every five sessions for what a script cannot see: contradictions between pages, superseded claims never corrected, missing cross-links, orphaned pages, drift in the conventions. The framework insists the next pass be scheduled by date in the baton, on the principle that a periodic rule nobody is prompted to check silently stops running — a prediction the project went on to confirm.

A.4 What a session did

A representative research session, reconstructed from the log, ran like this. Read the rules, the mission, the schema, the baton, the index. Confirm no stranded pull request and a current checkout. Take the queue’s top item — typically “a new word case study from a language family not yet covered” or a specific open lead on an existing word. Search the web; fetch candidate pages; when a fetch failed, retry with a plain command-line request identifying as a browser, or through a reader proxy, or by downloading a PDF and extracting its text with a tool installed for the purpose; when a page contained a quotation worth filing, fetch the raw page and confirm the words are there. File one source page per source read. Write or update the word page, citing every claim. Add a cross-reference from the pages the new page compares itself to. Update the index and the log; rewrite the baton with the queue re-prioritized and any new fence recorded; write the journal entry; run the link checker; commit with the project’s prefix, push, open a pull request, squash-merge it, and confirm that the main branch advanced. The rule of one unit per session was kept almost without exception: a new word took one session; a word’s remaining leads took one to six further sessions; a lint pass usually took a session of its own.

The rhythm over twelve days is visible in the log. Session 1 built the scaffold and wrote the first word page and the first theory pages; sessions 2 to 25 added the second and third words, worked their leads, and completed the translation-theory pages; from session 26 a new word arrived in nearly every session through session 50; sessions 51 to 61 were mostly gap-closing on the last three words, with the twenty-fifth word arriving at session 59. Lint passes ran at sessions 6, 13, 18, 25, 32, and 43, and one of them, at session 25, introduced a new mechanical check — a script comparing every source page’s “Used in” list against the wiki pages that actually cite it — that found and fixed four cases of stale metadata.

A.5 What the framework did well

Cold starts were cheap. A session with no memory was productive within minutes because the reading order put the state before the detail and forbade loading the whole wiki. The rewrite-only baton meant stale lines died; the fences meant blocked doors stayed shut — the OED wall, a defunct Inuktitut dictionary platform, an unreachable 2010 newspaper article, each tried repeatedly and then fenced, with a note saying what a genuinely new attempt would need. The source-page template did most of the work of honesty: a file that demands an exact quotation, a stance, an access date, and a Gaps section is hard to fill in carelessly, and the “record the disagreement” rule kept the project from resolving what its sources had not. The journal kept the owner informed at zero cost to the research. The mechanical link check was run before every commit and was clean wherever the log records its result (for seventeen sessions the result was not written down); the final tree is clean, and this site’s mirror was generated from it without a single broken internal link. And the framework’s permission to add machinery only when a real problem was observed was honored: the project added few standing rules of its own, and the most consequential — file nothing from a search tool’s synthesized answer without reading the raw source — came after the first fabricated quotation.

A.6 What it did less well

The framework’s own warning about periodic rules came true. The judgmental lint pass was deferred repeatedly — overdue at sessions 30 to 32 and again from 37 to 43 — because each session preferred a new word to housekeeping, and the general contradiction-and-staleness sweep across all twenty-five word pages, due on the framework’s schedule, never ran before close-out. Cross-references went stale in a way the framework did not anticipate: a new word page linked to the old pages it compared itself to, but the old pages were not revisited, so that by session 32 no earlier page linked forward to any later word; a mechanical check at session 43 found forty-two such gaps, and the close-out session found twelve more. The baton’s sixty-line cap was exceeded without a logged decision, and its fences section became the project’s most valuable and least structured artifact — a page of method knowledge that has no home in the wiki’s schema. The index’s one-line summaries became paragraphs. The project’s running taxonomy of “shapes of complication” grew by accretion and its numbering wobbled. And the mission’s own transition to its second phase — to be declared when the knowledge base could support survey-level answers — was never assessed: sessions kept adding words, and the synthesis the second phase called for is this essay, written at the owner’s request rather than at the project’s own judgment.

None of these failures corrupted a finding; all of them are the ordinary entropy of a growing document set, and the framework’s lint machinery was designed for exactly them. What the record suggests is that the machinery needs a harder trigger than a date in a queue — a session forced to lint before it may add — and that reverse links, metadata, and running taxonomies should be checked by script, not by hand, because the hand-tallies were incomplete every time a script was eventually run.

A.7 By the numbers

A.8 The close-out

On 8 September 2026 the owner switched off the schedule and started one interactive session with three instructions: wind up any research in progress, write this essay, and publish the knowledge base beside it. That session ran the reciprocal-link check and fixed the twelve gaps it found; normalized the stale word-counts in several pages’ cross-reference lists; wrote a closing entry in the log, a final owner’s report, and a close-out page in the wiki; rewrote the baton to record that no further session is scheduled while preserving the open leads for anyone who resumes; rendered every markdown file in the project as the HTML mirror linked throughout this essay; wrote the essay; had its claims and links checked by independent reviewing instances (whose findings are applied in this text); and merged the result to the repository’s main branch, from which this site is published. No research finding was changed at close-out, apart from a dated note correcting one stale count on a source record, which the review surfaced. The open leads are exactly where the sixty-first session left them.