This is the development record, published as it was written. It is amended by revision, including where the work went wrong. Nothing here has been rewritten for the web.

Record header

created_at: 2026-09-19T18:12:48-06:00
format: perspicuity-work/1
id: agent-eligibility-2026-09-19
next_check: 2026-10-03
record_status: open
revision: 7
skill_version: 0.4.0
updated: 2026-09-19
updated_at: 2026-09-19T20:00:00-06:00
work_status: submitted

Make small suppliers eligible to AI agents

Current position

Principal: David. Decider: David for the choice; Rook for the reversible implementation details within it. Work owner: Rook. Decision: inherited — the parent record next-project-choice/RECORD.md, a sibling project's record selects this project at revision 2, selected_at 2026-09-19T18:12:48-06:00. The frame, objectives, alternatives, comparison, scope decisions S1–S7 and the registered market test live there and are not repeated here. Work scope: the workspace, the architecture, the eligibility rubric, the auditor, the public site and the release scaffolding, to the point where implementation can start. Publication is outside this record's grant. Work: the repository exists at 0e2c8b2 with 46 tracked files, all 88 tests pass and make ci exits 0 — those are the revision-2 figures, kept as the scaffold's record; the tree is now 56 files and 105 tests. The catalogue holds 17 checks — 9 core, 8 recommended, 3 marked judgment rather than evidence. A real audit of example.com ran end to end through submit, queue, worker and static report. At revision 3 the process documents exist and the mechanical record check runs inside make ci; at revision 4 the actor-naming convention is added and the retrofit is assigned; at revision 5 the coordinator is named, the label is normalised, the process documents are revised and the corpus's first sub-record is filed; a first amendment corrects what that sub-record's independent check found; at revision 7 the cycle-one scope is selected and the corpus page is built from these records. docs/records/2026-09-19-hosting-and-public-corpus.md owns the published address and the corpus as a product surface. Outcome: unknown, and nothing about it is claimed. No external user has run a check, no supplier has been contacted and no revenue exists. Next: Rook — build U3–U5 of the cycle-one scope record, register each design choice before the code that depends on it, and report at go-live. David — choose the site's domain and give the go-live word; the domain is the only item on the critical path this record cannot move. The hand-off to "the first worker" is spent: docs/KICKOFF.md is the historical prompt that produced this session, and it is not a live instruction. Dependency: the site's domain (U3 in the parent) blocks U5 — going live — and nothing else. ELIGIBILITY_SITE_URL, the canonical links, sitemap.xml and the Caddy host block carry a placeholder until it is chosen. U3 and U4 are buildable now. Review due: 2026-10-03, the scope cap registered in the parent's plan.

The Review row's registered_at is revision 5 rather than the revision that opened the stage: the stage began at revision 4's assessment, and its criteria were not saved until revision 5 existed. The documentation time and the decision time differ throughout this record, and the entry under Registration order says which is which.

Frame and Decide

Prescribed work: David selected the course of action and the parent record holds its basis. No alternatives are invented here.

The one local framing contribution this record makes is the honest boundary of the product's claim. The report establishes what is mechanically checkable about a domain — which machine-readable surfaces exist, what they say, and whether they agree with each other. It does not establish that an agent will find, trust or recommend the supplier. Those are different claims with different evidence, and separating them is the reason a supplier should believe the free report over an agency's opaque score.

That boundary is not left as prose. tests/test_checks.py::ClaimBoundaryTests fails the build if catalogue wording drifts into a prediction.

The report page states the boundary in its own text, and the landing page carries a "what this is not" section, so a reader meets the limit before the result.

Architecture

Twelve component decisions, selected by Rook within its authority and recorded with their rejected alternatives in docs/ARCHITECTURE.md. The four that carry the most weight:

D1 is enforced rather than asserted: scripts/check_stdlib_only.py parses every module and fails on a non-standard import. Its one honest exception, Gunicorn as process manager, is recorded in the same document.

Process and corpus conventions

David's instruction of 2026-09-19 makes the decision corpus the backbone of the development process, asks for the conventions to be in place before the first worker starts, and asks for a naming convention for records. Three component choices, selected by Rook within its authority and written out in docs/RECORDS.md:

Rejected, with reasons: a per-topic directory tree (buries the chronology and multiplies the places to look); sequence numbers such as 001- allocated per record (two workers filing on the same day collide, and the listing loses its date).

Enforcement: make records runs the Perspicuity checker and make ci calls it, so a mechanically broken record fails the build. The checker's own limit is recorded in the same document — it is a spell-checker, not a reviewer, and a clean result establishes neither the reasoning nor the authority.

The corpus rule is stated literally in AGENTS.md and CONTEXT.md: every consequential choice exists as a record before the work that depends on it.

Naming the actors

David's instruction of the same day adds one more convention: an agent must name itself rather than appear in the corpus as a role word.

The problem is real and it is not cosmetic. The role word the coordinator's predecessor used is Perspicuity vocabulary for the coordinating agent; it means nothing to a reader outside the session that coined it. A model name is worse, because it changes under the work — a record that names the model cannot say who was accountable across a year. A chosen name is stable across model changes, which is exactly what a corpus meant to outlive its tools needs.

Rejected: keeping the role word and glossing it in a footnote (the jargon still leads every record); naming actors by model version (breaks on every model change); letting each session pick a fresh name (destroying continuity, which is the only thing a name is for).

This is recorded as a component choice rather than a separate record because it is a process convention in the same increment and shares its review. It sets a precedent later work follows, so if the first worker revises it materially, that revision belongs in the record it files — not here.

The retrofit was assigned at revision 4: the coordinator's chosen name replaces the historical label in revisions 1–3 of this record and throughout docs/ARCHITECTURE.md, recorded as a change entry with its reason. Rook completed it at revision 5. The facts do not change; only the label for the actor.

Process conventions after the first worker's review

Rook reviewed AGENTS.md, CONTEXT.md and docs/RECORDS.md with fresh eyes and revised them, then filed the review as the corpus's first sub-record. The findings are in that record; the three that change how work is done here are summarised because they bind this record too.

The naming rule is now checked. scripts/check_actors.py was added and make records runs it. It fails on one of five listed role words — the retired label, <!-- actor-naming: discusses-rule -->Coordinator, Assistant, Admin, Manager<!-- actor-naming: end --> — anywhere in the checked set, and permits a page to quote them only inside a marked block, in one of four places whose subject is the rule or its history. It is a denylist rather than a parser. A marked block must quote something forbidden and may not cover an actor credit or a roster row; a sentence that needs to name the words may carry a marker inline, covering that line alone. docs/ACTORS.md states what the check does and does not catch. David asked for this to be checkable rather than asked for politely; the alternative was to leave the convention as prose and review it by eye.

Registration and filing are separated. The corpus rule already said a record precedes the work that depends on it. It did not say how, and the file's two moments — registering the identity, position, frame and choice before dependent action, then filing the Act evidence, Review findings and Changes entry after it — were only visible in the practice of this record, not in the convention. They are now written down in docs/RECORDS.md, with a registered-but-empty ## Act named as a correct state so a worker does not fill it in early to look finished.

What each check covers is now written down. The record checks are a front-matter checker and a prose actor checker, neither of which reads the reasoning, the authority or the work. The exact file set is listed, with the files deliberately outside it — docs/RUBRIC.md because it is generated, docs/KICKOFF.md and the other guides because they are scaffolding built from these documents and kept in step by hand.

Cycle one: what is delivered

David accepted the process increment on 2026-09-19 and instructed Rook to open the next phase from the core decisions about what the project actually delivers. That choice is its own sub-record, registered at 72c1810 with the frame and the alternatives committed before the comparison that used them — the practice the previous increment documented and did not follow.

Rejected: a service-only course with no product surface (fastest to ten audits, but it tests David's outreach rather than the product); the journey plus the paid tier (does not fit the 14-day window, conflicts with the no-accounts constraint, and needs a data-retention record before any code).

The scope cap is 2026-10-03. If the domain cannot be chosen within a few days, the fallback registered in that record is the service-only course, because the window is the binding constraint rather than the build.

Decision index

Two sub-decisions are filed. The first is the worked example later records follow; David accepted it on 2026-09-19 after the independent check, and the corrections it required are in its revision 2. The second records what cycle one delivers and carries the increment now under way.

Act

What this increment was, and how it stands against the registered plan

The parent's plan registered U1 as "complete the eligibility rubric and check catalogue, and submit it for David's review before U2 begins". His instruction of 2026-09-19 — spin the workspace up, make it a repo, settle the architecture and get it ready to start — authorized a wider increment. That amendment is recorded rather than glossed: U2 and U3 were scaffolded in the same pass, and the review point moved from "before U2" to "before publication". Nothing is published, so the delivery gate is untouched.

Registration order

The architecture choices and the plan were drafted before the code they govern, and the parent's selection was saved before this record existed. Revision 2 and the whole scaffold increment are the exception in this record's history: they were completed on 2026-09-19 between 18:12 and 18:30, and the account of them was written at 18:29:59, which is a documentation time and not the time of the decisions. The earlier times in the timing table are the observed ones, and the U1–U4 evidence in ## Act is retrospective in that one respect.

Revision 5 closes that gap as a convention rather than as an apology. docs/RECORDS.md now separates registering a record — identity, position, frame and choice, before the work — from filing it, after. The two are the same file at two moments, and a record registered with an empty ## Act is in a correct state. Nothing in this record's history is rewritten to make it look as though it were registered first; the exception is recorded here instead, which is what a later reader needs to judge how much weight the timing evidence carries.

Material failures found and corrected

Three defects were found by the checks rather than by inspection, and each is recorded because the finding is worth more than the fix:

1. **wsgi.input.read(4096) hung the submit endpoint.** It blocked on a socket-backed stream whenever the client sent less than the buffer. Corrected to read exactly CONTENT_LENGTH, which is what WSGI requires. Found by the end-to-end smoke test; the unit tests had used an in-memory stream and could not see it.
2. Multicast addresses passed the SSRF guard. ipaddress.is_global reports 224.0.0.1 as global on this Python, so the guard now names its exclusions explicitly instead of inferring them. This was a real hole in a security boundary, and the test caught it.
3. The redirect loop followed one hop more than it claimed. max_redirects=3 followed four. Corrected so the bound means what it says.

Two further defects were caught by tests before any commit: JSON-LD was injected into the report page unescaped, so a hostile domain name could close the script element; and the CI script used a pipeline under set -e, which would have masked a failing test suite behind tail's exit code.

Checks that did not exist before this increment

ClaimBoundaryTests (catalogue wording), the standard-library guard (D1), the rubric-freshness check (D4) and the no-JavaScript guard on the public pages. Each converts a claim this record makes into something the build enforces.

Review

| The market test becomes runnable before 2026-10-03 | U5 and the live host | Rook builds; David chooses the domain and the word; window to 2026-10-03 | Pending | The service-only fallback is registered if the domain slips |

| Ten real audits by people who are not us | The queue; the suppliers' own words | David owns outreach; Rook owns the tooling | Not started | This is the parent's registered test, not this record's |

Delivery acceptance is separate from benefit. This increment's delivery is a working workspace plus a corpus with one record in it. It establishes no user, no need met and no revenue, and no check run against a stranger's site constitutes either. The revision-5 increment delivers conventions; whether they make better records is not observable yet and is not claimed.

Changes

Revision 1, 2026-09-19T18:12:48-06:00. Created at selection with the parent link. Source: David's selection of the agent eligibility check. Reason: the parent's prospective plan names this record as its first unit, and the choice had to be saved before dependent action. Affects: units U1–U4. No code, host, file outside this directory, spend or outbound contact was touched.

Revision 2, 2026-09-19T18:29:59-06:00. Records the infrastructure and scaffold increment at 0e2c8b2. Source: David's instruction of the same day to spin the workspace up as a repo, settle the architecture and get it ready to start. Reason: the increment was completed and the record has to carry what exists, what was found and what deviates from the registered plan. Changes: revision 1 is preserved at 0e2c8b2; work status moves from active to submitted; the architecture component decisions are indexed with a link to their full account; the U1–U4 table gains actual evidence; the amendment to the review point is recorded; three material defects and two pre-commit corrections are preserved; the Review section is opened with findings. No earlier basis is relabelled.

Revision 3, 2026-09-19T19:01:00-06:00. Adds the process and corpus conventions and the materials the first worker starts from. Source: David's instruction of the same day to make the clean decision corpus the backbone of the development process, to have a naming convention in place, to give the project a context document, and to prepare a kickoff prompt. Reason: the corpus rule existed only as an intention; nothing enforced it, and no convention existed for naming or admitting a record. Changes: CONTEXT.md states the product, the two required outcomes, the corpus rule, the claim boundary, the scope fences and the stop conditions; docs/RECORDS.md carries the location, naming, admission, linking, skeleton, publication-hygiene and delegation rules; AGENTS.md is rewritten around the method and names the first task; docs/KICKOFF.md holds the prompt; TODO.md records the open items, the domain first; make records and scripts/check_records.sh put the mechanical record check into make ci. The three process choices and their rejected alternatives are recorded above with an index. No selection, objective, test or reversal condition in revision 1 or 2 is altered, and no earlier basis is relabelled. Nothing is published, spent or sent.

<!-- actor-naming: discusses-rule --> Revision 4, 2026-09-19T19:05:07-06:00. Adds the actor-naming convention and assigns the retrofit. Source: David's observation that agents write Primary for the coordinating agent, which reads badly in a record intended for publication, and his instruction that the coordinator name itself. Reason: the corpus is written for strangers and must outlive the models that produced it; a role word is jargon and a model name is unstable. Changes: docs/ACTORS.md is created with the naming rules, the roster and the retrofit note; docs/RECORDS.md gains an Actors section and attributes delegated returns to a named worker; AGENTS.md moves naming to the first step of the first task and adds it to the read-first list; docs/KICKOFF.md carries the same in the prompt; TODO.md records the parent record's fifteen Primary references as a decision for someone else. The convention and its rejected alternatives are recorded above. The Primary references in revisions 1–3 of this record and in docs/ARCHITECTURE.md are deliberately not rewritten here — the coordinator normalises them to its own chosen name and records that normalisation itself, so the label change is attributable to the actor it renames. No selection, objective, test or reversal condition is altered. Nothing is published, spent or sent.

Revision 5, 2026-09-19T19:15:07-06:00. Names the coordinator, normalises the retired label, revises the process documents and files the corpus's first sub-record. Source: David's instruction of the same day to the first worker — name yourself, own the process documents, and file the first record before any feature work; and his instruction that the Primary references in revisions 1–3 and in docs/ARCHITECTURE.md be normalised, with the normalisation recorded as a change entry. Reason: the corpus is written for strangers, and the two things it could not yet survive were an unnamed coordinator and a naming rule that nothing enforced. Changes: Rook is named and the roster, the candidates not chosen and the label's history are in docs/ACTORS.md; the retired label is normalised in revisions 1–3 of this record and throughout docs/ARCHITECTURE.md, with the facts unchanged; scripts/check_actors.py and tests/test_actor_check.py are added and make records runs the check, so the naming rule now fails a build rather than asking politely; AGENTS.md, CONTEXT.md and docs/RECORDS.md are revised — registration separated from filing, the checked file set and both checkers' limits written down, the sub-record lifecycle and the delegation naming rule stated, and the read order corrected so docs/ACTORS.md precedes the document that refers to its names; the first sub-record is filed and the decision index now lists it. This revision was written after the work it records; the earlier revisions' timing evidence is untouched and the exception is stated under Registration order rather than glossed. No selection, objective, test or reversal condition in revisions 1–4 is altered. Nothing is published, spent or sent.

Revision 6, 2026-09-19T19:24:40-06:00. Amends revision 5 after the independent check on the sub-record it filed. Source: Verity's report to David of the same day, commissioned by Rook at 19:15:07. Reason: four of its findings were material and one of them was a hole in the new check, so the increment could not stand as filed or as the worked example later records copy. Changes: scripts/check_actors.py now tests each marked block on its own rather than the concatenation, so a live block no longer licenses a stale one beside it, and it fails on a block that covers an actor-credit field or a roster row — the escape hatch the check demonstrated against itself, and the reason docs/ACTORS.md had to be restructured so its roster sits outside the marked rule text; an inline marker form was added for the one sentence that has to name the words, and a marker confined to RECORD.md's ## Changes section was tried and then dropped as a rule that protected nothing the actor-credit guard does not; tests/test_actor_check.py grows from 17 cases to 23, one per demonstrated exploit and one per marker-parsing rule; the rule is now described everywhere as five listed role words rather than "a job title", because a denylist that catches five words does not catch a sixth; RECORD.md's Next no longer points at a first worker's return that cannot come, docs/KICKOFF.md is marked as the spent prompt rather than a live hand-off, and the revision-2 figures in Work are labelled as belonging to revision 2; the sub-record is amended at its revision 2 with the assessor named, the landing commits (2cf38fc, 5ff06c8, 58ced5c) in place of a placeholder, the corrected counts, and its own overclaims narrowed. No selection, objective, test or reversal condition in revisions 1–5 is altered, and the revision-5 text is preserved in Git at 2cf38fc. Nothing is published, spent or sent. <!-- actor-naming: end -->

Revision 7, 2026-09-19T19:39:40-06:00. Accepts the process increment on David's word, opens the next phase, and moves the record's work state. Source: David's acceptance on 2026-09-19 — "I will accept all of these" — and his instruction to start the next phase from the core decisions about what is delivered. Reason: an accepted increment changes what the record is for; it now carries a live build against a registered scope rather than a submitted one. Changes: the sub-record is marked accepted by David and its revision-2 corrections are noted; the cycle-one scope record is filed and indexed with the delivery shape, the publish decision, the deferred list and the fallback; the dependency is narrowed to the domain, which blocks go-live and nothing else; Next moves from assessment to building U3–U5; the Review gains the two rows the open window turns on. No selection, objective, test or reversal condition in revisions 1–6 is altered. Nothing is published, spent or sent; no product code was written. Same day, later: Authority moved out of Current position into its own section, because three records link to it and a link to a label is not a link to a section. Work gains the corpus page's landing revision.

Authority

Inherited from the parent selection and David's standing grants. Spending, outbound messages, external agreements and the release word for publication remain with David. This record adds no authority of its own, and the sub-records below add none either.