issues: four records of today's landings, checked against the code and the CI logs

issues/a-crate-new-to-the-published-set-reds-every-publish-until-someone-puts-it-up-by-hand.md

@@ -0,0 +1,46 @@
+---
+status: open
+kind: tooling
+opened: 2026-10-20
+---
+
+# A crate new to the published set reds every publish until someone puts it up by hand
+
+`publish.yml` publishes through crates.io trusted publishing, and a trusted
+publishing token cannot create a crate. #905 (2c3f61a3e) put `toyos-untrusted`
+and `toyos-transport` into `PUBLISHED` (`build/sdkversion.rs`), std's
+dependencies through `library/Cargo.lock`, and neither exists on crates.io. So
+main's 27 `publish` runs from 38558545002 (2c3f61a3e, 2026-10-14) to
+39497368165 (9b11608ab, 2026-10-20) are red: 25 at the first new crate, and two
+stopped earlier, 38719407453 at a git clone and 38727675385 at a moved tip.
+The 25 answer
+
+> failed to publish toyos-untrusted ... (status 403 Forbidden): Trusted
+> Publishing tokens do not support creating new crates. Publish the crate
+> manually, first
+
+The crates after it in `PUBLISHED` have not gone up since: `toyos` and
+`toyos-window` were last published on 2026-10-14 at 10:06Z.
+
+The nightly's `release` reads the same plan, finds `toyos-untrusted` owed at
+main's tip, and refuses (`release::sdk_at_tip`): "crates.io holds no
+toyos-untrusted of this tree, main's tip, so no sdk alias can name it". Runs
+38701484274, 38868708235, 39013160165, 39108067326, 39221595037 and
+39390441510 are red so, and the newest toolchain release and `sdk-` alias are
+nightly 38533374419's, `toolchain-linux-x86_64-sdk-0.71.0` (2026-10-14 08:16Z). The refusal is right here and names the symptom, not the
+failed publish (`issues/a-release-that-decides-before-its-tips-crates-are-up-reds-the-nightly.md`).
+
+The publish runs' and the releases' log lines, and crates.io's answers:
+https://github.com/ToyOSOrg/evidence/tree/a36ad035c72df67b46d2ccee7a916fe5f521a5a3.
+
+Only an account can create a crate, and only then can it name `publish.yml`
+the crate's trusted publisher. Nothing before a landing tells that a crate it
+adds to `PUBLISHED` is not on crates.io.
+
+Owner: the owner's crates.io account for the first versions; `build/sdkversion.rs`
+for the rule.
+
+**Exit**: `toyos-untrusted` and `toyos-transport` are on crates.io, each naming
+`publish.yml` its trusted publisher; a `publish` run at main's tip and the next
+nightly's `release` are green; and `PUBLISHED`'s doc comment says a crate joins
+it only once crates.io holds it under that publisher.

issues/a-driver-that-lends-its-device-a-handle-a-peer-sent-is-ended-when-it-is-no-region.md

@@ -0,0 +1,37 @@
+---
+status: open
+kind: defect
+opened: 2026-10-20
+---
+
+# A driver that lends its device a handle a peer sent is ended when it is no region
+
+`SYS_DEVICE_DMA_MAP` takes its region with `HandleTable::get`
+(`sys_device_dma_map`, `kernel/src/syscall/device.rs`), so a handle of another
+kind is `HandleError::WrongType`, which ends the caller, exit 139
+(`process::handle_fault`). `HandleTable::get_sent` answers `InvalidArgument`
+for it instead, and is what `SYS_SPAWN` and `SYS_NAMESPACE_BUILD` take a
+handle a peer sent with (`kernel/src/object/handle.rs`).
+
+The region a holder lends is a peer's by contract: `toyos_pci_claim::lend`
+maps "`region`, which a peer lent", and reads `InvalidArgument` as
+`Unlendable` (`lib/pci-claim/src/lib.rs`), a refusal the kernel never answers
+for a handle of another kind. Since #953 the hda driver lends its controller
+the ring soundserver sent with its acceptance, unchecked
+(`offered` and `toyos_pci_claim::lend` in `system/hda/src/main.rs`): a
+soundserver that sends a pipe end or a connection there ends hda rather than
+being refused. diskserver is not reached, because `SharedMemory::lent` refuses
+what `SYS_FSTAT` does not answer as a region before it maps one
+(`system/diskserver/src/region.rs`). A region's kind is one `SYS_FSTAT` settles,
+so this is not `issues/a-received-handle-has-no-knowable-type.md`'s case.
+
+The kernel owns the fix rather than each lender: what a holder lends is a
+peer's by `lend`'s contract, and the kernel already answers a peer's handle of
+the wrong kind `InvalidArgument` at `SYS_SPAWN` and `SYS_NAMESPACE_BUILD`; a
+check before every lend would repeat that in each driver.
+
+Owner: the kernel's device calls (`kernel/src/syscall/device.rs`).
+
+**Exit**: `SYS_DEVICE_DMA_MAP` takes its region through `get_sent`, and
+`HandleError::WrongType`'s comment names it beside `SYS_SPAWN` and
+`SYS_NAMESPACE_BUILD`.

issues/the-boot-volumes-server-holds-a-claim-that-writes.md

@@ -6,15 +6,22 @@ opened: 2026-10-10
 
 # The boot volume's server holds a claim that writes
 
+The boot volume is the ESP firmware loaded the loader from (`Role::Boot`,
+`kernel/src/gpt.rs`): on the image the build writes it carries the loader and
+`toyos/log.guid`, which the loader reads beside itself; the kernel and its
+parameter are on the booted slot's volume (`Role::Slot`), which no file server
+serves (`create_esp_volume` and `create_slot_volume`, `build/image.rs`).
+
 On a disk the kernel drives — the boot stick, until usbd serves it — the
-supervisor endows the boot volume's file server a partition claim on the
-running slot's volume (`storage_endowment`, `system/supervisor/src/main.rs`).
-A claim carries `Rights::WRITE` and no `DUP` (`initial_rights`,
-`kernel/src/object/ops.rs`), so nothing can hand that server a duplicate
-narrowed to reading: the volume the loader reads the kernel from stays
-unwritten only by that server's promise to mount it read-only. On a disk the
-block service serves, the same server's grant does not write, and diskserver
-answers a write through it `ReadOnly` (`block_grants_reach_their_partitions`).
+supervisor endows the boot role's file server a partition claim on the ESP
+(`storage_endowment`, `system/supervisor/src/main.rs`). A claim carries
+`Rights::WRITE` and no `DUP` (`initial_rights`, `kernel/src/object/ops.rs`), so
+nothing can hand that server a duplicate narrowed to reading: the loader
+firmware runs stays unwritten only by that server's promise to mount the ESP
+read-only (`fat_on(disk, writable)`, `system/fileserver/src/main.rs`). On a
+disk the block service serves, the same server's grant does not write, and
+diskserver answers a write through it `ReadOnly` before the device sees it
+(`system/diskserver/src/main.rs`'s module header).
 
 **Exit**: the boot volume's server on the boot stick holds a partition it
 cannot write — a read-only session once usbd serves the stick, or a claim the

issues/the-host-caches-limit-reaches-the-10-gb-only-through-one-measured-ratio.md

@@ -55,9 +55,25 @@ that run is red and saves nothing. Until an entry is sealed again, a pull
 request restores the last sealed one, or runs cold once the runner image has
 moved; either way its verdict is its steps'.
 
+That is main's state since 2026-10-15, the second time, after 2026-10-05's
+(`issues/a-red-nightly-on-main-is-reported-to-nobody.md`). Every scheduled
+`host` since is red at its seal and only there, every earlier step green: run
+38701484274 (979d4c539) counted 8,034,022,781 B in 17,193 files, and runs
+38868708235, 39013160165, 39108067326, 39221595037 and 39390441510, all at
+0e6716fc0, 8,033,230,395 to 8,033,351,794 B in 17,181 files. The last entry
+saved is run 38533374419's (f0a987bc6, 2026-10-14): 7,293,414,884 B in 15,246
+files sealed, and the cache list says it stores 1,867,126,459 B, a ratio of
+3.91. The fifteen landings f0a987bc6..979d4c539 added 740,607,897 B and 1,947
+files; which of them did is not measured. The 8 GB is this module's bound on
+uncompressed bytes, not GitHub's: at that ratio the refused tree would store
+about 2.06 GB. The repository's list held 10,562,836,502 B in 24 entries on
+2026-10-20 regardless, the host entry and 23 toolchain layers. The seal lines of
+these runs and that cache list: https://github.com/ToyOSOrg/evidence/tree/a36ad035c72df67b46d2ccee7a916fe5f521a5a3 (`nightly-host-seal`, `cache-list.json`).
+
 Owner: the host cache (`build/cicache.rs`).
 
-**Exit condition.** Two gates that red:
+**Exit condition.** Nightly's `host` seals and saves main's tree again, and
+three gates that red:
 - after nightly's `host` saves, a step reads that entry's stored bytes and every
   toolchain layer's from the repository's cache list, and fails when 2H + T
   passes 10 GB;