Skip to content

docs: complete Ames task coverage and add a Gifts section - #279

Open
sigilante wants to merge 1 commit into
urbit:masterfrom
sigilante:docs/pr6a-ames-cards
Open

docs: complete Ames task coverage and add a Gifts section#279
sigilante wants to merge 1 commit into
urbit:masterfrom
sigilante:docs/pr6a-ames-cards

Conversation

@sigilante

Copy link
Copy Markdown
Contributor

Fourteenth PR from the audit against urbit/urbit@08026c84b2. Ames was the worst-covered vane by a wide margin.

Union In source Documented before
+$ task:ames (lull.hoon:844-902) 37 15
+$ gift:ames (lull.hoon:926-946) 15 0

Coverage after this PR: 35/37 tasks, 15/15 gifts, verified by script. The two remaining — %halt and %goad — are added by #269, which owns that region of the file. This PR appends and deliberately does not touch the %heed/%jilt sections #269 replaces.

I test-merged the two together: the combined ames/tasks.md has all 37 tasks documented and zero %heed/%jilt.

Companion PRs: #266, #267, #269, #270, #271, #272, #273, #274, #275, #276, #277, #278.

Tasks added, grouped by purpose

Flow and peer management%cork (delete a flow, negotiated with the peer), %kroc (delete specific flows by bone; the bulk form), %tame (delete a cached route), %dear (manually associate a ship with a lane), %deep (deferred self-calls), %stun (STUN response from Unix), %prod (re-send a packet per flow), %cong (congestion parameters; backs |ames/cong), %trim.

Remote scry key reservation%plug, and %gulp for |mesa.

Directed Messaging migration%mate, %rege, %load. %load sets which core is used for new peers and defaults to %ames, so communication with older peers is always possible.

Mesa protocol tasks%heer %mess %moke %meek %mage %rate %prog %whey, listed as a group and marked internal to Ames and the runtime. Documenting each individually would imply they're sendable from userspace, which they aren't.

Descriptions come from the source's own comment block above the union (lull.hoon:812-841) wherever it provides one, so the wording matches the kernel author's intent rather than my inference. %plug and %gulp have no comment there; both are handled by +sy-plug (ames.hoon:11562), described in source as "key reservation for %shut namespace" — which is what the entries say.

Gifts section

All 15 cards, split into messaging, remote scry, system and mesa groups. Union block checked against lull.hoon by script.

Two verification notes

  • An intermediate coverage script reported %flub and %live as undocumented Ames tasks. They are not tasks — the regex had matched them inside comment text on lull.hoon:901-902. Re-ran with comments stripped before trusting the result. Worth mentioning because "missing card" findings are exactly what gets acted on.
  • An earlier draft linked %deep to [$deep](data-types.md#deep), but that anchor is added by docs: replace removed Ames %heed/%jilt with the backpressure protocol #269 and doesn't exist on master. The reference is prose instead, so this PR doesn't depend on merge order.

All anchors verified to resolve. Test-merged against the thirteen open companion PRs — all clean.

🤖 Generated with Claude Code

Against urbit/docs.urbit.org@08026c84b2. Ames was the worst-covered vane by a wide margin:
`+$ task:ames` (lull.hoon:844-902) has 37 cards and ames/tasks.md documented 15;
`+$ gift:ames` (lull.hoon:926-946) has 15 cards and NONE were documented.

Coverage after this PR is 35/37 tasks and 15/15 gifts, verified by script. The
two remaining, %halt and %goad, are added by the Ames backpressure PR, which
owns that region of the file -- this PR appends and deliberately does not touch
the %heed/%jilt sections that PR replaces.

Tasks added, grouped by purpose rather than dumped in one list:

  Flow and peer management
    %cork  delete a message flow, negotiated with the peer
    %kroc  delete specific flows by bone; the bulk form of %cork
    %tame  delete the cached route for a ship
    %dear  manually associate a ship with a lane, from unix
    %deep  deferred calls to ames, from itself
    %stun  STUN response or failure, from unix
    %prod  re-send a packet per flow; all peers if .ships is ~
    %cong  adjust congestion control parameters; backs |ames/cong
    %trim  release memory

  Remote scry key reservation
    %plug  reserve a key for the %shut namespace
    %gulp  the same, for |mesa

  Directed Messaging migration
    %mate  migrate peer(s) to |mesa
    %rege  regress peer(s) back to |ames
    %load  set which core is used for NEW peers; defaults to %ames so that
           communication with older peers is always possible

  Mesa protocol tasks
    %heer %mess %moke %meek %mage %rate %prog %whey, listed as a group and
    marked internal to Ames and the runtime. These are not sendable from
    userspace and documenting each individually would imply otherwise.

Descriptions are taken from the source's own comment block above the union
(lull.hoon:812-841) wherever it provides one, so the wording matches the
kernel author's intent rather than my inference. %plug and %gulp have no
comment there; both are handled by +sy-plug (ames.hoon:11562), described in
source as "key reservation for %shut namespace", which is what the entries say.

Gifts section covers all 15 cards, split into messaging, remote scry, system
and mesa groups. The union block was checked against lull.hoon by script.

Two verification notes:
  - An intermediate coverage script reported %flub and %live as undocumented
    Ames tasks. They are not tasks; the regex had matched them inside COMMENT
    text on lull.hoon:901-902. Re-ran with comments stripped before trusting
    the result.
  - An earlier draft linked %deep to [$deep](data-types.md#deep), but that
    anchor is added by the backpressure PR and does not exist on master. The
    reference is prose instead, so this PR does not depend on merge order.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant