Capture Home execution route, LEARN profile, privilege policy and release/board lessons in Atlas

.agents/skills/atlas/assets/seed/records/04d17203f03279980862496517a1f0861be5f6cc8063bfbf92f8f8ac19744fdd.json

@@ -0,0 +1 @@
+{"citations":[{"path":"src/FS.GG.Telemetry.Host/Program.fs","repository":"FS-GG/.github","revision":"fa3e87f8d0ee1548c4a57e0d6cb2d17ae04e7f5a","sha256":"2413eee3f1e5382e2a2b6a762d19a7d9664691243e558291c4245788746775ea"},{"path":"src/FS.GG.Telemetry.Host/HostRuntime.fs","repository":"FS-GG/.github","revision":"fa3e87f8d0ee1548c4a57e0d6cb2d17ae04e7f5a","sha256":"69e2d02f5e69fce58c2f8e452f40a6152d66d5f723ace6edc23a2d901f350e32"},{"path":"docs/coordination/telemetry-host-release.md","repository":"FS-GG/.github","revision":"fa3e87f8d0ee1548c4a57e0d6cb2d17ae04e7f5a","sha256":"700f3dad1c25d8d8467fcca40f005e6de7bd2b99424262bf267ccffbeac8e678"}],"conflictsWith":[],"id":"github/home-utel-receiver-host-0-8-state","kind":"boundary","recordedAt":"2026-10-23T08:27:28Z","repository":"FS-GG/.github","schema":"fsgg.atlas/1","status":"recorded","summary":"Supersedes the 2026-10-22 15:20Z version, which still described the first passive send as only expected. The facts are live and operational; refresh them from the receiver before action.\n\nState: Host 0.8.0 serves the schema-14 store store14-v1 (FS-GG/.github#4707 comment 6342802444; #4516 comment 6342801775). The step 3d cutover committed at 14:05Z on 2026-10-22 after a 21.4 s outage, and independent review accepted it with all 36 recorded gates true. The previous schema-12 store (uv12) is kept at its seal for rollback. The rollback window runs to 2026-10-23 14:10Z, and rolling back discards anything ingested on uv14.\n\nFirst durable receipt, accepted (#4705 comment 6344445603; #4705 closed 2026-10-22). Credential home-passive-programme-v1 was enrolled at 15:05Z for producer codex-passive-home-01, stream native-usage, workspace utel-home-20261003 (rowDelta receipt_producers +1). The send at 15:14Z returned durably-received, and the transport_receipts row was applied with the producer's envelope digest. Lifetime receipts went 4->5. Batch passive-94ef3481...-1 (25 events) produced exactly one current fact per identity, with correctionsTotal 0.\n- Still pending: batch 2 (24 events). Draining it needs a newly admitted credential delivery.\n- Unknown: programme/activity attribution. The attribution tables stayed 0, so the receipt proves ingest and admission only.\n- Retained Unknowns: one unread health_diagnostics row; a 198 B payload_bytes difference that is probably framing; and the receiver does not log which credential reference authenticated, so that is inferred from the exact producer/stream binding.\n\nPost-window steps: store retention, root-owned leftovers and the batch-2 credential re-delivery were admitted as exact-hash scripts. They run as fsgg-store-dev where possible, through /etc/sudoers.d/fsgg-admitted, which the user installed at 16:23Z on 2026-10-22 (#4516 comments 6345413503, 6345724325). They are scheduled after the rollback window ends. Policy: environment/home-least-privilege-policy.\n\nMechanics, from source and review:\n- Credentials load only when serve starts, so enrolling needs a serve restart.\n- enroll-producer needs the credential already declared in config with matching fields. It runs under the service lock, and it writes through INSERT OR IGNORE, so exit 0 can hide a no-op; check status and the row delta.\n- /private/health accepts any non-revoked config credential. Dashboard login is separate and rate limited per process.\n- status run through podman exec while serve holds the lock reports process 'unknown', which is not a failure.\n- Accepting a receipt needs the applied transport receipt, not just the 202.\n\nEarlier rollbacks: admission 3 refused at P2 on an over-strict WAL/shm gate. Admission 4 failed on operator probe defects (a process=='running' requirement, and dashboard 429s caused by re-running health checks). Both rolled back cleanly before admission 5 committed (github/admitted-privileged-script-lessons).\n\nLimits: dated observations. The published Host contract stays in contract/telemetry-host. This record grants no enrollment, send, drain, retention or rollback authority.","supersedes":["f4de28905adbfe6ae4bc38f8bf5f47a444aa8d0f2023faaa431d6f72f9a3edea"],"tags":["utel","telemetry-host","host-0.8.0","schema-14","store14-v1","receipt","enrollment","rollback-window","operational-state","home"],"title":"Home UTEL receiver serves Host 0.8.0 on schema-14 store14-v1; first durable receipt accepted; post-window steps pending"}

.agents/skills/atlas/assets/seed/records/482cd15ecd9cfbd8e1943c0fcde0bbf1d875392dc2a701b698f48bfba684a062.json

@@ -0,0 +1 @@
+{"citations":[{"path":"docs/adr/0013-trusted-publishing-oidc-for-nuget-org.md","repository":"FS-GG/.github","revision":"fa3e87f8d0ee1548c4a57e0d6cb2d17ae04e7f5a","sha256":"1d2d71d19ab6354834acafd843f44c2fe6e99e4c8ca2e0d522424f7b2bfc2893"},{"path":".agents/skills/publishing-and-deployment/SKILL.md","repository":"FS-GG/.github","revision":"fa3e87f8d0ee1548c4a57e0d6cb2d17ae04e7f5a","sha256":"39a8ed8cede8c470090df9bc35f0036bae4ad030bfb846505599db298b8a4cb6"},{"path":".github/workflows/execution-pair-forward-publish.yml","repository":"FS-GG/FS.GG.Coordination","revision":"bc3c504b3df5c2de97c9df1ea584014c668d5ce5","sha256":"3e16e3ef8eebad9c24792ae6877ce5f83f05d6081f54fd79292b3c51c849cf3c"},{"path":".github/workflows/callable-cli-release-publish.yml","repository":"FS-GG/FS.GG.Coordination","revision":"bc3c504b3df5c2de97c9df1ea584014c668d5ce5","sha256":"ac736727db6dbf7a4d4c16d8daea9e9e684a2bca32c970389b4df80324a44908"},{"path":".github/workflows/release-telemetry-host.yml","repository":"FS-GG/.github","revision":"fa3e87f8d0ee1548c4a57e0d6cb2d17ae04e7f5a","sha256":"e233ecf159aa8cd5920ddd80c9e05798f7d45c0c0210f073b44f21c0c50d589a"}],"conflictsWith":[],"id":"github/nuget-trusted-publishing-policy-scope","kind":"lesson","recordedAt":"2026-10-23T08:27:28Z","repository":"FS-GG/.github","schema":"fsgg.atlas/1","status":"recorded","summary":"Finding by fdev (FS-GG/FS.GG.Coordination#1026 comment 6358900581, 2026-10-23), from a live re-read of the default-branch release workflows in all FS-GG repositories.\n\nA nuget.org GitHub Trusted Publishing policy matches the owner, repository, workflow file name and, only when it is set, the environment. It has no ref or branch field; ADR-0013 records the same policy shape. So under any policy without an environment, a same-named workflow file on any branch that has id-token: write can mint a push key for every package the policy's glob allows. A '*' glob turns this into a second writer for unrelated IDs.\n\nBranch rulesets do not close the gap:\n- The Coordination main-protected ruleset covers only ~DEFAULT_BRANCH.\n- Branch creation is open to the admins, and every fdev agent authenticates as the same admin account, so a creation ruleset would need that account in its bypass list.\n- A branch copy has actually run under a release file name: run 37971715740 ran callable-cli-release-publish.yml on a push to a routine branch on 2026-10-09.\n\nDisabling a workflow does fence it, because a disabled workflow is keyed by its path and the policy's file name equals that path.\n\nFence plan decided for the FS.GG.Execution.* old writers (steps 1-2 are the user's nuget.org pass, still pending at capture):\n1. Narrow each policy's glob to the IDs its producer actually owns.\n2. Delete the policies of retired producers.\n3. Do not let a dormant or fail-closed job keep a second glob alive. Add a temporary scoped policy as part of any later recovery admission instead.\n4. Optionally, add a main-only environment to each policy and its job. This needs workflow changes in each repository.\nBefore relying on a single-writer claim, recursively check that no other repository contains the package projects.\n\nAt capture the fence was partial. Two workflows were disabled (.github release-telemetry-host.yml and Coordination callable-cli-release-publish-011.yml), and a personal-repository publish job is held behind an environment with required reviewers. The nuget.org UI narrowing pass listed in the comment is a user step and was still pending. Unproved: whether nuget.org matches a reusable-workflow call by job_workflow_ref. ADR-0013 separately records that a cross-repository reusable-workflow token exchange fails with 401. The narrowed-glob fence does not depend on either.\n\nLimits: policy state, workflow enablement and ruleset membership are live facts; re-read them before relying on the fence. This grants no publication or policy change.","supersedes":[],"tags":["nuget","trusted-publishing","oidc","release","workflow","branch","ruleset","policy","supply-chain","execution-pair"],"title":"nuget.org Trusted Publishing policies have no branch field: without an environment, a same-named workflow on any branch can mint"}

.agents/skills/atlas/assets/seed/records/a476183540f2e7121e533bf2dd9125dc071c81acc880e88cb435cad7a6d35b97.json

@@ -0,0 +1 @@
+{"citations":[{"path":"docs/coordination/worker-channels.md","repository":"FS-GG/.github","revision":"fa3e87f8d0ee1548c4a57e0d6cb2d17ae04e7f5a","sha256":"51fff6066a11de80fb1cb29b9c44cc3cc58299119f3b5da91373b4835c066d87"},{"path":"docs/coordination/diagnostic-execution.md","repository":"FS-GG/.github","revision":"fa3e87f8d0ee1548c4a57e0d6cb2d17ae04e7f5a","sha256":"7d1f1bcdd177c826fe1a38d58cb1a710956ac96a8bb93cedb482be736da2ed92"},{"path":"docs/designs/2026-10-13-provisioned-podman-execution.md","repository":"FS-GG/.github","revision":"fa3e87f8d0ee1548c4a57e0d6cb2d17ae04e7f5a","sha256":"c8de752fa8308487ac31165bf93ef9c769915f1279f488cef6973ce8735cbb6a"}],"conflictsWith":[],"id":"environment/home-least-privilege-policy","kind":"decision","recordedAt":"2026-10-23T08:27:28Z","repository":"FS-GG/.github","schema":"fsgg.atlas/1","status":"recorded","summary":"User-agreed policy, relayed by fdev on 2026-10-22 (FS-GG/.github#4516 comment 6344780731; Home receipt 6345020952). It applies to every future admitted step on Home.\n\n1. Routine operation needs no root: receiver, producers, health and dashboard.\n2. Admin steps run as the owning service account (fsgg-store-dev for UTEL, fsgg-learn-qual for LEARN). They use a narrow sudoers rule that names the admitted script by its sha256, for example: eugen ALL=(fsgg-store-dev) NOPASSWD: sha256:<hash> /path/<script>. Scripts must not create root-owned files. fdev additionally required the LEARN scripts that ran during the window below to carry an euid gate, so they run unchanged under pinned sudo afterwards (6346571312).\n3. Root is used only where unavoidable, through hash-pinned sudoers entries. fdev posts the exact lines for the admitted hashes. The user installs them once with visudo (for example /etc/sudoers.d/fsgg-admitted, installed 2026-10-22 16:23Z for the UTEL post-window steps). Home runs exactly those, and the entries are removed afterwards. There are no time-boxed root shells.\n4. Prompt-injection guard: Home treats only fdev posts that cite an exact script sha256 as admissions, and verifies the hash itself. The pinned entry enforces this technically.\n\nIn production each consumer has its own pinned file (LEARN: fsgg-learn), and only the service-account operator entry stays standing (#4777 comment 6358880288). A standing root entry for a new purpose, such as SC2 prepare/bind, extends this policy and needs a user decision first. Until then each privileged step is a per-operation user install and remove.\n\nTemporary exception, not policy: on 2026-10-22 at 17:06Z the user suspended the policy for 24 h (6346556877). The user-authenticated home-root terminal was authenticated at 17:21Z and hard-stops at about 2026-10-23 17:21Z (6346880328). During the window, only fdev-admitted exact hashes run, each announced, with no retry and no ad-hoc root, reads included. fdev directed the UTEL post-window steps to stay on the pinned path. The policy resumes on expiry. Author's guidance, not a sourced rule: do not treat the window as a precedent.\n\nThis complements github/admitted-privileged-script-lessons. Its exact-bytes review, dry-run and single execute still apply, now carried out through pinned sudoers instead of a root terminal.\n\nLimits: this is a user policy recorded from public comments, and the user can change it. Installed sudoers content is a live fact; read it on Home. This record grants nothing.","supersedes":[],"tags":["home","privilege","least-privilege","sudoers","service-account","policy","root","admission","prompt-injection"],"title":"Home least privilege: service-account operation, hash-pinned sudoers for unavoidable root, no standing root shells"}

.agents/skills/atlas/assets/seed/records/ad0e6d78c1e450e19bfca4a0e904644ab0ae315607811a28ac3dba20de869786.json

@@ -0,0 +1 @@
+{"citations":[{"path":"docs/roadmaps/2026-10-13-provisioned-podman-execution.md","repository":"FS-GG/.github","revision":"fa3e87f8d0ee1548c4a57e0d6cb2d17ae04e7f5a","sha256":"ce3a905edb383cb298d36771868c63bff655dfcac3cb646e243f4b9f81c6eebe"},{"path":"docs/designs/2026-10-13-provisioned-podman-execution.md","repository":"FS-GG/.github","revision":"fa3e87f8d0ee1548c4a57e0d6cb2d17ae04e7f5a","sha256":"c8de752fa8308487ac31165bf93ef9c769915f1279f488cef6973ce8735cbb6a"},{"path":"docs/roadmaps/2026-10-07-unified-development-roadmap-v3.md","repository":"FS-GG/.github","revision":"fa3e87f8d0ee1548c4a57e0d6cb2d17ae04e7f5a","sha256":"6c1ef9a67fe9a84811ce1cd0e100862e76de951e838a460172cbd16d158d4fd7"}],"conflictsWith":[],"id":"platform/shared-bounded-execution-route","kind":"decision","recordedAt":"2026-10-23T08:27:28Z","repository":"FS-GG/.github","schema":"fsgg.atlas/1","status":"recorded","summary":"Decision by fdev under user-delegated coordination authority, revocable by the user (FS-GG/.github#4777 comment 6358880288, 2026-10-23; delegation recorded in #4516 comment 6339514027), amended by LEARN erratum E5 (#4777 comment 6359588237). It answers #4777; the cited V3-ENV plan keeps owning the common provisioning outcome and its milestones are unchanged. Detailed LEARN state: learn/home-finite-host-profile. Privilege rules: environment/home-least-privilege-policy.\n\nRoute (a) is selected: the existing Home host, following the pattern LEARN has accepted with gaps on production. Home/SystemAdmin operates it with one service account per consumer (LEARN: fsgg-learn-qual); fdev admits exact hashes and accepts results. Production authentication is a per-consumer hash-pinned file under /etc/sudoers.d/ (LEARN: fsgg-learn) that the user installs once with visudo. Root install entries are removed after use, and only the service-account operator entry stays. The 24 h root terminal is not the production route.\n\nRoute (b), a dedicated managed runner, is not selected. There is no supplier, cost or capability evidence for it. An off-Home runner cannot reach LEARN's existing installation or bind SC2's filesystem into the fdev namespace, and either would change acceptance. A runner on Home is (a) plus a service. Re-entry needs a scoped migration decision, and only if (a) cannot supply SC2 privileged setup/binding, an SC2 I/O bound, or an unattended caller-invocable entrypoint.\n\nLimits per op (transient units plus podman): 1 CPU; 2 GiB with swap 0; 512 tasks; 256 MiB / 4096-member output; hard kill at 32:24; no network. Aggregate on user-30034.slice, as amended by E5: CPUQuota=200%, MemoryMax=6G, TasksMax=1280. These were originally 5G/1152 and were raised because the idle slice use (~0.97 GB) would stop a second full op. At most 2 concurrent ops, enforced under an exclusive lock. Headroom is measured against the slice (2.5 GiB / 576 tasks), and the host MemAvailable guard stays. Custody free space must be at least 1 GiB x (active + 1). The evidence-size refusal threshold is EVID_MAX_BYTES = 32 GiB of allocated bytes, walk-bounded at 2^20 entries; an unmeasurable tree refuses. Home proposed it in #4516 comment 6359528534, fdev accepted it in 6359541244, and it ships in C2 r5b (admitted 6360031719). Read I/O is unbounded and is an explicit coverage limit, because no io controller is delegated.\n\nCleanup: the finalizer unit starts first and the op BindsTo it (fail-closed). Both run under user@30034, and the payload runs as host uid 428679. The finalizer verifies retirement and writes hash-chained records, and the sweep refuses on failed units or orphans. Reboot or user-manager loss writes no record; reconciliation belongs to #4650. Rollback is per consumer: C1 --uninstall, then remove that consumer's sudoers file. Evidence and Unknown holds are kept.\n\nConsumers: LEARN (#4745) keeps its genuine installation, and its acceptance establishes nothing for SC2 (#4746). SC2 reuses the delivered binder, storage helper and frozen profile, but its prepare and bind steps need root for every operation. A standing root sudoers entry for them would extend the user-agreed privilege policy, so it needs a user decision on #4746 first. Until then each privileged step is a per-operation user install and remove. SC2 still owes system-unit limits, an I/O bound (or a scoped coverage-limit decision), fixed-worker placement, finalizer-style custody and host/guest correspondence. As operated, route (a) is Home-agent-mediated per run. It does not by itself meet #4650's unattended gate, and the selection must not foreclose that gate. #4647 and #4650 are unchanged.\n\nCost recorded: no purchase. LEARN took about 16 h elapsed on 2026-10-22, with about 6 user authentications and one 24 h root grant. SC2 effort is unmeasured. This record is a decision index, not an operation grant. Refresh installed state and slice values on Home before action.","supersedes":[],"tags":["decision","execution-route","home","finite-profile","learn","sc2","sudoers","slice","limits","v3-env"],"title":"SC2 and LEARN share the Home finite-profile execution route; a dedicated managed runner is not selected"}