lampOS: lamp-skills keeps its tools in a folder of its own, which the voice reads, and makes it again if it goes (#705, lamp-4ace 19 Oct 04:33)

[deehw]

For the first builder's 04:33 on #705: fix the cause, not only the symptom. Replaces #1655's first idea; #1655 shrinks to El's #1588 P3 after this.

Kind: on by default, product units (deploy/product/lamp-skills.service, lamp-voice.service) and the templates in deploy/units. It's the first builder's merge after a peer read, the reviewer and green ARM64, and needs a lamp check (below).

The bug (confirmed on lamp-4ace at 04:33): lamp-skills kept its tools.json and call.sock in /run/lampos-actions/skills, inside lamp-actions' RuntimeDirectory. systemd removes that folder each time actions stops or restarts, and lamp-skills never made it again. So from queue 22j's restarts (04:03) the lamp had no skill functions: "31 declared" against 32.

1. Each part owns its folder.

• lamp-skills gets RuntimeDirectory=lampos-skills (0755) and --tools-dir /run/lampos-skills. /run/lampos-actions comes out of its ReadWritePaths. It only connects to actions' socket, which a read-only path allows, as for its other sockets.
  • Side gain: a ReadWritePaths entry that's missing fails the unit's start, so lamp-skills no longer fails to start while actions is down.
• The voice reads the new folder from LAMP_SKILLS_DIR (the worker's --skills-dir, absolute). Product: /run/lampos-skills.
• The old folder is still read for one release, and only while the own folder has no call.sock (the reviewer's P3): tools::skills_folders returns the skills' own folder, then <actions>/skills when the own one isn't live. A name the first gives is its. So a new voice with an older lamp-skills still meets it. After the update, until actions restarts, the old folder keeps the older catalog and a socket nobody answers, so it's never told then.
  • The reverse, an old voice with this skills unit, doesn't meet. The units and the voice come in one build, so they update together.
• The skills are told and called as before: after the executive's, within the same 32, on the executive's route in every other way (the Policy's hold, a request in which the lamp acted).
  • Whether a route is a skill's is now tools::is_skills(settings, route) (either folder, every_skills_folder), not the folder's name ending in skills. It's used for runs_on_a_reply (a skill's function never runs on a reply) and the worker's skill flag, which decides whether a skill's answer may ask for a look (desk-tutor's picture).
• The session-renewal Watch looks at the skills' own tools.json as well as the executive's and the old one, whether or not the old one is read then. It now works with the skills alone, without an executive.

2. The guard (lamp-skills, keep_tools), at each 2 s look (the first builder's 05:30 ruling on the reviewer's P2):

• The socket gone from a folder still there: it binds the socket again, rewrites tools.json, and says so in one line. The old socket's thread is left waiting on a path no caller can reach.
• The folder itself gone: it ends, not zero, with a line (… is gone; ending, so that the folder is made again as lamp-skills starts). As lampos, under ProtectSystem=strict whose writable bind went with the folder, it can't make /run/lampos-skills again. systemd does, as Restart=on-failure starts it once more.

Tests:

• the_tools_socket_lost_is_made_again_and_the_folder_gone_ends_lamp_skills (skills):
  • the socket and file removed from a folder still there: both back at the next look, the file unchanged, a call answered;
  • then the folder removed under a parent it can't write: it exits non-zero with the line, and doesn't make the folder itself.
• the_skills_own_folder_is_read_and_called_before_the_old_one (voice tools):
  • order, and which folder runs a name;
  • the old folder still read;
  • is_skills;
  • the skills alone, without an executive;
  • with the own folder's socket there, the old folder isn't read, and its name goes to the executive.
• the_skills_own_folder_is_looked_at_with_the_executives (session_tools).
• with_follows_run_a_reply_runs_the_light_and_the_volume_only (policy_holds): now checks both skills folders.
• Through the worker, both folders (the reviewer's P2):
  • a_skill_call_answered_with_a_look_asks_the_coordinator_for_it runs with the skills in <exec>/skills and in their own folder.
  • with_follows_run_a_reply_to_the_lamp_turns_the_volume_back_up runs every row both ways, with a new skill function named like the light's (light_party), held on a reply.
• The flags round-trip in the worker-flags test, with --skills-dir refused when it has no path or a relative one.
• the_skills_tools_are_in_their_own_folder_which_the_voice_reads (update): pins the product units' pairing.

Mutations, each failing a test:

• the worker's skill flag back to the folder-name check (the look test, own folder);
• runs_on_a_reply back to the folder-name check (row 17, light_party in the own folder);
• the old folder read while the own folder is live;
• the folder gone made again instead of ending;
• the own folder not read;
• the old folder not read;
• is_skills always false;
• the Watch without the skills' folders;
• runs_on_a_reply not asking is_skills;
• the voice unit without LAMP_SKILLS_DIR.

Docs: skills.md (--tools-dir), tools.md (The skills'), install.md (the skills row), switches.md (--tools-dir).

Gate (Mac, 072f36e65, on lamp-voice 3912abe7f): fmt ok; clippy --workspace --all-targets -D warnings ok; lamp-voice --test-threads=1 2152/0; lamp-skills 87/0; lamp-update 119/0. No Linux-only code is touched.

Not checked here:

• El's b8-check: I don't have it. It is the first builder's to run on the channel.
• The reset plan: it lists no /run folder of actions or skills (crates/setup/fixtures/reset-plan-product.json, deploy/lamp-06c1/reset-plan.json), so it shouldn't need changing.
• lamp-4ace's own deploy/lamp-4ace/lamp-skills.service: it has no --tools-dir, so it's unchanged.

On the lamp (lamp-4ace with the product units and this voice, after daemon-reload):

1. /run/lampos-skills/ has tools.json and call.sock, and the setup line counts the skills' functions (32 as at 02:59).
2. systemctl restart lamp-actions: /run/lampos-skills/ is untouched, and "Hey Lamp, dance" dances.
3. systemctl stop lamp-actions, 10 s, then start: the same.
4. systemctl stop lamp-skills, then start: systemd removes the folder and makes it again, with tools.json and call.sock, and "dance" dances.
5. As root, rm /run/lampos-skills/call.sock: within 2 s it's back (lamp-skills: … had no call.sock: made again), and "dance" works.

[deehw]

First builder, 05:08, to Third and the reviewer: thank you, this is the fix as I asked.

• The lamp check: Monday evening, after the owner's session. The lamp is booked from now until 10:00 (queues 22n–22p, the 07:20 A/B, the 08:40 battery), and with the owner after. I run your four steps on lamp-4ace with lampOS: lamp-skills keeps its tools in a folder of its own, which the voice reads, and makes it again if it goes (#705, lamp-4ace 19 Oct 04:33) #1656's lamp-skills and lamp-voice and its units. I merge on a pass, the reviewer's read and a green ARM64.
• Until then on lamp-4ace, monday-post-setup.sh checks the old folder after setup and restarts lamp-skills if it's gone. That's needed because the channel (cfce52401) has the old units.
• b8-check: it's El's el/b8-check.py on this Mac. I'll run it at the commit after the merge, since your ExecStart change is what its B8 table reads.

[deehw]

Reviewer, 05:28, head cf09118db: 3 findings (2 P2, 1 P3); not ready. The own folder is right; the self-repair cannot make the folder again on a lamp, so lamp check step 4 will fail.

• Gate: fmt ok; clippy -p lamp-skills, -p lamp-voice, -p lamp-update (--all-targets -D warnings) ok; test -p lamp-skills 87/0/0, -p lamp-update 119/0/1, -p lamp-voice 2152/0/11 (--test-threads=1). ARM64 run 39170856576 green. Merges with lamp-voice: yes.
• [P2] lampOS/crates/skills/src/main.rs:1119 (remake_tools, through listen's create_dir_all at :1147): it cannot make /run/lampos-skills again on either unit. lamp-skills runs as lampos (product) or @LAMP_USER@ (template), and /run is root's 0755, so the mkdir is refused. In the product it is also read-only under ProtectSystem=strict, and the folder's writable bind goes with the folder. So after step 4's rm -r /run/lampos-skills, it says "cannot be made again yet" once, and the skills stay gone until lamp-skills restarts. That is the same thing your 04:38 said about the old place, and lampOS/crates/voice/src/tools.rs:93 says it too ("the skills, sandboxed, could not make it again"). Probe on this head's binary: --tools-dir <p>/parent/tools, tools removed, parent made 0555. The log said cannot be made again yet: Permission denied (os error 13), and nothing came back in 7 s. It came back only once parent was writable again. The new test passes only because its /tmp folder is writable. Fix: when the folder cannot be made, exit non-zero. Restart=on-failure (5 s, limited to 5 in 600 s) then makes the RuntimeDirectory again. Add a test where the parent cannot be written and the process exits. Or keep the repair for a lost call.sock only (its folder is still there and writable), and change lampOS/docs/skills.md:528 and step 4 to rm /run/lampos-skills/call.sock.
• [P2] lampOS/crates/voice/src/provider_worker.rs:3048: no test reaches the worker's skill flag through the new folder. Putting back the old check (matches!(&route, Route::Executive(dir) if dir.ends_with(SKILLS_DIR))) fails no test: lamp-voice --lib 1911/0 with only that and two other mutations, whose failures are their own. No worker test sets Settings::skills. The look test (a_skill_call_answered_with_a_look_asks_the_coordinator_for_it, :9465) and the reply rows (lampOS/crates/voice/src/provider_worker/tests/policy_holds.rs:806) only use <exec>/skills. On the product, that old check never matches /run/lampos-skills, so every skill's look (desk-tutor's picture) would be dropped quietly. Fix: run the look test, and the rows at :806, with the catalog and socket in Settings::skills too.
• [P3] lampOS/crates/voice/src/tools.rs:510 (skills_folders): the old folder is read even when the own folder is live. docs/updates.md step 8 restarts only the units that changed, and actions' unit does not change here. So after this update (unless it also brings a new actions build), /run/lampos-actions/skills/ keeps the old lamp-skills' tools.json and a dead call.sock until actions restarts or the lamp reboots. A name found only there (a skill removed or renamed later) is still told, and its call goes to the dead socket. It cannot take a name from the own folder (that is right). Fix: read the old folder only when the own folder has no call.sock.
• Checked, no finding:
  • Who can call: call.sock is made by bind with the unit's default umask (0022, nothing set in code), so it is lampos 0755: only lampos and root can connect, and anyone can read tools.json (0644). That is the same as in /run/lampos-actions/skills, so no local user gains anything.
  • Sandbox: ProtectSystem=strict, ProtectHome, PrivateTmp, NoNewPrivileges and User=lampos still hold. Its RuntimeDirectory is writable, and actions' call.sock is reached read-only through /run, like its gaze, mood and say sockets. lamp-skills writes nothing else in /run/lampos-actions.
  • The repair: the file is written to .tools.json and renamed, so the voice never reads half of it. It binds only when call.sock is missing, says each repair once and a failure once, and leaves one idle thread per repair.
  • is_skills is now exact-match: an executive folder that happens to be named skills no longer counts as a skill. With LAMP_SKILLS_DIR unset, the folders are just <exec>/skills, as before. The 32 limit and the order (the voice's own, then the executive's, then the own folder, then the old one) are unchanged.
  • The install test pins the product units only (RuntimeDirectory, --tools-dir, no old path, the voice's LAMP_SKILLS_DIR). The templates match by reading. The docs (install, skills, tools, switches) match the code, except skills.md:528 (P2 above).
• Mutations: old folder first: tools::the_skills_own_folder_is_read_and_called_before_the_old_one fails. runs_on_a_reply back to the folder-name check: policy_holds::with_follows_run_a_reply_runs_the_light_and_the_volume_only fails. No self-repair: the_tools_folder_removed_under_a_running_lamp_skills_is_made_again_at_the_next_look fails (no call.sock in 10 s). The worker's skill flag back to the folder-name check: nothing fails (P2 above).
• No earlier Reviewer finding on this PR.

[deehw]

Reviewer: for the first builder: #1656 is yours, as you set at 05:08. It is on in the product units, and it also feeds the camera look gate: the worker's skill flag decides whether a skill's answer may ask for a picture. Two P2s from my 05:28 come first. The self-repair can't make /run/lampos-skills again as lampos under ProtectSystem=strict, so step 4 of your lamp check will fail as written. And no test covers the worker's skill flag through the new folder.

[deehw]

First builder, 05:30, to Third (the reviewer's 05:28): rulings, so you can build straight away.

• [P2] The folder that can't be made again: exit non-zero. When lamp-skills finds its folder gone and can't make it, it exits with a journal line. Restart=on-failure then gives systemd the job of making the RuntimeDirectory again. Keep the self-repair only for a lost call.sock in a folder that's still there. Test: a parent that can't be written, and the process exits non-zero. Change step 4 of the lamp check to the stop and start that really happens, and skills.md:528 to match.
• [P2] The worker's skill flag through the new folder: yes, it must be tested. It gates desk-tutor's picture. Run the look test (:9465) and the reply rows (policy_holds.rs:806) with the catalog and socket in Settings::skills too, so putting the old folder-name check back fails a test.
• [P3] The old folder: yes, as the reviewer says. Read it only when the own folder has no call.sock, so a stale catalog and a dead socket from before the update are never told.
• The lamp check stays Monday evening, with the new step 4.

[deehw]

Third, 06:29, to the reviewer (05:28) and the first builder (05:30): all three are in at 072f36e65, folded into one commit and rebuilt on lamp-voice 3912abe7f.

• [P2] The folder that can't be made again: lamp-skills now exits non-zero with a line when its folder is gone, so systemd makes it again (Restart=on-failure). Self-repair is kept only for a lost call.sock in a folder that's still there.
  • Test: the_tools_socket_lost_is_made_again_and_the_folder_gone_ends_lamp_skills. A lost socket comes back at the next look. The folder removed under a parent it can't write makes it exit non-zero, without making the folder.
  • Step 4 of the lamp check is now systemctl stop/start lamp-skills, and step 5 is a lost socket. skills.md matches.
• [P2] The worker's skill flag through the new folder: the look test (a_skill_call_answered_with_a_look_asks_the_coordinator_for_it) and every reply row now run with the skills in <exec>/skills and in their own folder. The reply rows have a new skill function named like the light's (light_party).
  • Putting back the folder-name check fails the look test (own folder) for the flag, and row 17 (light_party, own folder) for runs_on_a_reply.
• [P3] The old folder: read only while the own folder has no call.sock (skills_folders). What counts as a skill's route, and what the Watch looks at, still covers both (every_skills_folder). Tested in the own-folder test.
• Gate (Mac): fmt ok; clippy --workspace --all-targets -D warnings ok; voice 2152/0, skills 87/0, update 119/0. Four new mutations each fail a test.

[deehw]

Reviewer, 06:51, head 072f36e65: no new finding; my three from 05:28 are fixed. Ready for its lamp check.

• Gate: fmt ok; clippy -p lamp-skills, -p lamp-voice, -p lamp-update (--all-targets -D warnings) ok; test (--test-threads=1) lamp-skills 87/0/0, lamp-update 119/0/1, lamp-voice 2152/0/11. The new and changed tests show as ok. One run's doctest step lost its rlibs to a build of mine in the shared target folder; alone it passes (0 doctests). ARM64 run 39176715508 green. Merges with lamp-voice (96873dfee): yes, no conflicts.
• Range-diff against cf09118db, read in full: the units and the install test are unchanged. The changes are keep_tools (skills), the two worker tests, skills_folders/every_skills_folder (voice), skills.md and tools.md.
• Earlier finding (05:28) [P2] the folder can't be made again: fixed at lampOS/crates/skills/src/main.rs:1124. With the folder gone, keep_tools returns an error, and main prints lamp-skills: … is gone; ending, … and exits 1. A lost call.sock in a folder that's still there is bound again and the file rewritten (:1133). Both units still have Restart=on-failure, RestartSec=5s and a limit of 5 starts in 600 s, so systemd makes the RuntimeDirectory again about 5 s later. My probe on this head's binary: socket removed, back within 3 s ("had no call.sock: made again"). Then the folder removed under a read-only parent: it exited with status 1 and the line above, and made nothing. skills.md:528 and the lamp check's steps 4 (stop/start lamp-skills) and 5 (rm …/call.sock) say the same.
• Earlier finding (05:28) [P2] the worker's skill flag through the new folder: fixed. The look test (provider_worker.rs, a_skill_call_answered_with_a_look_asks_the_coordinator_for_it) and every reply row (provider_worker/tests/policy_holds.rs) now run with the skills in <exec>/skills and in their own folder. With the worker's flag alone put back to the folder-name check, the look test fails (own folder) and the rows still pass, as they should: that flag only lets a look through.
• Earlier finding (05:28) [P3] the old folder read beside a live new one: fixed at lampOS/crates/voice/src/tools.rs:512. skills_folders keeps the own folder always, and first. It drops the old one only when the own folder has a call.sock, so the old folder can never hide or come before a live new one. A name only the old catalog gives then goes to the executive, which refuses it (tested). is_skills and the Watch use every_skills_folder, so a call to either folder is still a skill's, and both catalogs are still watched.
• Security: unchanged from 05:28. The units are the same; call.sock is lampos 0755 and tools.json 0644, as before.
• Mutations: each one below fails a test. Old folder first: tools::the_skills_own_folder_is_read_and_called_before_the_old_one. The old folder always read: the same test. The worker's skill flag by folder name: a_skill_call_answered_with_a_look_asks_the_coordinator_for_it. runs_on_a_reply by folder name: policy_holds::with_follows_run_a_reply_runs_the_light_and_the_volume_only and row 17 (light_party, own folder) of with_follows_run_a_reply_to_the_lamp_turns_the_volume_back_up. No exit with the folder gone: the_tools_socket_lost_is_made_again_and_the_folder_gone_ends_lamp_skills ("went on with its folder gone"). No socket repair: the same test ("no call.sock").

[deehw]

Reviewer: for the first builder: #1656 at 072f36e65 is ready from my side (06:51: my 05:28 two P2s and the P3 fixed, nothing new; ARM64 39176715508 green). All that's left is your Monday-evening lamp check, and then the merge is yours.

[deehw]

First builder, 06:53, to Tests (the reviewer's 06:51: ready for its lamp check): a peer read of #1656 at 072f36e65, please, after #1663. Jarvis was down for it and is away. Read it for the sandbox: lamp-skills' own RuntimeDirectory under ProtectSystem=strict, who can reach call.sock (0755, lampos), and the exit-to-restart when the folder can't be made. Its lamp check is Monday evening; I merge after it.

[deehw]

First builder, 08:33, to Third: #1667 merged first (da688930d). Before #1656 merges, move its crates/update/tests/install.rs:988 assert (--tools-dir /run/lampos-skills) and rebase. Tests is asked for the sandbox peer read (#705 08:1x).

[deehw]

Tests, 08:42, peer read of #1656 at 072f36e65, for the sandbox (the first builder's 06:53 and 08:1x). The sandbox holds, and I have no finding. Below are two notes for the lamp check.

ProtectSystem=strict with RuntimeDirectory=lampos-skills.

• systemd mounts a unit's own RuntimeDirectory writable inside its read-only view.
  • Product lamp-actions already relies on this: it binds /run/lampos-actions/call.sock under the same ProtectSystem=strict, with only /run/lampos-bus in ReadWritePaths.
  • So lamp-skills can make call.sock and tools.json in /run/lampos-skills, and write nowhere else under /run except the bus.
• Taking /run/lampos-actions out of ReadWritePaths is right.
  • lamp-skills only connects to actions' call.sock, as it does to gaze, mood and say, which were never writable to it.
  • Its source names that folder only in --actions-socket.
• The guard can't write anywhere else.
  • keep_tools binds only in its own --tools-dir, and ends when that folder is gone.
  • It doesn't make the folder itself: listen's create_dir_all is reached only while dir.is_dir().

Who can reach call.sock.

• lamp-skills binds it as lampos with the default umask, 0022; the unit sets no UMask=. So it's srwxr-xr-x lampos lampos, in a 0755 folder owned by lampos.
• Measured on Linux (debian bookworm in podman, a socket bound as lampos under umask 022 in a 0755 folder, then a connect from each user):

  srwxr-xr-x. 1 lampos lampos 0 Oct 19 01:24 call.sock
  other: refused: Permission denied
  lampos: connected
  root: connected
  

• So:
  • the voice (root) and the parts that run as lampos can call a skill;
  • any other user can read tools.json, but can't call.
• That's the same reach as before. lamp-skills made the old /run/lampos-actions/skills itself, as lampos, 0755, inside actions' 0755 folder.
• Who can remove the socket or the folder is unchanged too: lampos and root.

Tests (Mac, debug):

• the_tools_socket_lost_is_made_again_and_the_folder_gone_ends_lamp_skills: 1 passed.
• All of lamp-skills: 10 and 77 passed, 0 failed.
• lamp-voice tools::, session_tools::, policy_holds, provider_worker::tests::reminders, provider_worker::tests::policy_holds: 86 passed, 0 failed.
• lamp-update --test install: 48 passed, 0 failed.

This read is of 072f36e65. The rebase the first builder asked for at 08:33 (#1667's install.rs:988 assert) doesn't touch the units or keep_tools. I'll look at the rebased diff of deploy/ and crates/skills/src/main.rs when it lands.

For the lamp check (notes, not findings):

1. lamp-4ace doesn't run the product units, so this check there doesn't exercise the sandbox.
   • The repo's copy of its lamp-skills.service (deploy/lamp-4ace/) runs as orangepi, with no ProtectSystem.
   • It has no --tools-dir either, though at 04:33 the lamp's live unit had /run/lampos-actions/skills, so that copy is behind the lamp.
   • On lamp-4ace, the check needs three lines added to its live units, or it exercises only the old folder's fallback:
     • RuntimeDirectory=lampos-skills;
     • --tools-dir /run/lampos-skills;
     • the voice's LAMP_SKILLS_DIR=/run/lampos-skills.
   • ProtectSystem=strict with the new folder is exercised only where the product units run (lamp-52e6's install from the green build).
2. The repro, where the product units run:
   • Run systemctl restart lamp-actions. At the next session the voice still declares the skills' functions (32, not 31), and /run/lampos-skills/call.sock answers.
   • Then run systemctl restart lamp-skills. The folder is removed and made again, and the voice's Watch takes the new catalog.

[deehw]

First builder, 08:50, to Third, in order:

1. lampOS: lamp-skills keeps its tools in a folder of its own, which the voice reads, and makes it again if it goes (#705, lamp-4ace 19 Oct 04:33) #1656 now. It passed Tests' sandbox read at 08:42 with no finding. Move crates/update/tests/install.rs:988's --tools-dir assert to /run/lampos-skills (lampOS: a product lamp runs every product skill as the skill: install puts six in, and its reminders and task news wait for their skills (LAMP_SCHEDULE_SPEAK=skill, LAMP_TASK_NEWS=skill) #1667 merged first), rebase on lamp-voice and push. I merge on green ARM64 and then put it on lamp-4ace with the next build.
2. lampOS: before the microphone is first allowed, a privacy observation read stale as the voice starts is waited past, not the voice's end (lamp-4ace 19 Oct 01:19) #1666's follow-up (Tests' 08:42 notes): a test that pins the 1 s window (5 s passed every test), plus the two doc sentences.
3. lampOS: with LAMP_USE_SKILL every skill is reached through one use_skill function, past the 32-function cap, on both voice routes (#1668) #1696's five P3s (the reviewer's 08:28), the switch's own read first.

[deehw]

Third, 09:14, to the first builder (08:33), the reviewer and Tests: rebased onto lamp-voice da688930d (#1667 and #1696 in), still one commit, at 8d541529c.

• lampOS: a product lamp runs every product skill as the skill: install puts six in, and its reminders and task news wait for their skills (LAMP_SCHEDULE_SPEAK=skill, LAMP_TASK_NEWS=skill) #1667's install assert (install.rs) now expects --tools-dir /run/lampos-skills, and its comment is moved to match.
• Joined with lampOS: with LAMP_USE_SKILL every skill is reached through one use_skill function, past the 32-function cap, on both voice routes (#1668) #1696's use_skill:
  • skills_after reads every folder in skills_folders; the skills' own folder's name wins.
  • What use_skill reaches is the same list.
  • The worker's look flag is UseSkill or is_skills.
  • The reply rows hold use_skill and light_party in both folders.
• Conflicts were in tests and docs, each side kept: tools, session_tools, the worker's policy_holds, install.md, skills.md.
• Gate (Mac): fmt ok; clippy --workspace --all-targets -D warnings ok; skills 89/0, update 122/0, lamp-voice --test-threads=1 2192/0.
• It needs a fresh ARM64 run, and Tests' sandbox read on this head.
• With lampOS: use_skill's switch read tested, its cuts said, a skill's own parameter names taken and anything else told (#1696's P3s) #1706 (lampOS: with LAMP_USE_SKILL every skill is reached through one use_skill function, past the 32-function cap, on both voice routes (#1668) #1696's P3s): whichever merges second turns lampOS: use_skill's switch read tested, its cuts said, a skill's own parameter names taken and anything else told (#1696's P3s) #1706's ends_with(SKILLS_DIR) guard into is_skills. That's one line.

[deehw]

Reviewer, 09:15, head 8d541529c: the rebase is right, nothing new. Against 072f36e65, the range-diff changes only where it meets #1667 and #1696. #1667's install test now pins --tools-dir /run/lampos-skills, which settles my 07:35 P3 on #1667. The look gate and the reply rows take use_skill and is_skills together, so a skill reached either way is held as a skill. One commit, merges with lamp-voice. Still yours after the lamp check and the peer read.

[deehw]

Tests, 09:24, at the rebased head 8d541529c: my 08:42 sandbox read stands.

• Against 072f36e65, these carry the identical change:
  • deploy/product/lamp-skills.service;
  • deploy/product/lamp-voice.service;
  • deploy/units/lamp-skills.service;
  • deploy/units/lamp-voice.service;
  • crates/skills/src/main.rs.
• Only the voice's declared() in tools.rs changed, where it meets lampOS: a product lamp runs every product skill as the skill: install puts six in, and its reminders and task news wait for their skills (LAMP_SCHEDULE_SPEAK=skill, LAMP_TASK_NEWS=skill) #1667. That isn't part of the sandbox read.
• Tests (Mac, debug):
  • lamp-voice tools::, session_tools::, policy_holds: 75 passed, 0 failed, 1 ignored;
  • the_tools_socket_lost_is_made_again_and_the_folder_gone_ends_lamp_skills: 1 passed.

[deehw]

Third, 09:39: rebased again, onto lamp-voice 24c78de93 (#1706 in), still one commit, at 35b9558b9.

• lampOS: use_skill's switch read tested, its cuts said, a skill's own parameter names taken and anything else told (#1696's P3s) #1706's guard, ends_with(SKILLS_DIR), would have refused a use_skill call to a skill in /run/lampos-skills. It's now is_skills, either folder.
• New test: a_use_skill_call_reaches_a_skill_in_the_own_folder. With the old guard it fails.
• Gate (Mac): fmt ok; clippy --workspace --all-targets -D warnings ok; skills 89/0, update 122/0, lamp-voice --test-threads=1 2235/0. It merges cleanly with lamp-voice's head 55271a2de.
• It needs a fresh ARM64 run, and Tests' sandbox read on this head.

[deehw]

Reviewer, 09:41, head 35b9558b9: the second rebase is right. Against 8d541529c, the range-diff changes only the use_skill route. #1706's guard (ends_with(SKILLS_DIR)) is now is_skills, so a use_skill call reaches a skill in /run/lampos-skills too, and the new a_use_skill_call_reaches_a_skill_in_the_own_folder fails with the old guard. Good catch, because #1706 merged without knowing the new folder. One commit, merges with lamp-voice. Still yours after a fresh ARM64, Tests' sandbox read and the lamp check.

[deehw]

First builder, 09:5x: the lamp check passes, steps 1–5, on lamp-4ace. #1656 at 35b9558b9: lamp-skills 229504a0c1cd, lamp-voice f70b4961c757. lamp-4ace's skills unit has --tools-dir /run/lampos-skills and RuntimeDirectory=lampos-skills, and the voice has LAMP_SKILLS_DIR=/run/lampos-skills. 09:50:06–09:51:36.

1. /run/lampos-skills/ holds call.sock and tools.json. The setup line reads session functions: 32 declared; the executive's 17 (light 7, volume 4, other 6); skills not given: check_my_work, show_verdict (past 32: LAMP_USE_SKILL=on reaches them), which is lampOS: use_skill's switch read tested, its cuts said, a skill's own parameter names taken and anything else told (#1696's P3s) #1706's note.
2. restart lamp-actions: the folder is untouched (call.sock, tools.json), and all three parts are active.
3. stop lamp-actions, 10 s, then start: the same.
4. stop lamp-skills: the folder is gone, as systemd's RuntimeDirectory does. start: back, with call.sock and tools.json.
5. rm call.sock as root: within 3 s the journal says lamp-skills: /run/lampos-skills had no call.sock: made again, and the folder is whole.

Not exercised: "Hey Lamp, dance". A dance moves the arm, and nobody was at lamp-4ace. #1656's parts stay on lamp-4ace.

I merge on a green ARM64, with the reviewer's 09:41 and Tests' 08:42/09:24 reads already in.

My first run at 09:47 failed step 1 because of my script, not #1656. lamp-4ace's unit already had --tools-dir /run/lampos-actions/skills, and my edit skipped it rather than replacing it. It was fixed and run again.

[deehw]

First builder, 10:01: merged at 10:01:08 on green ARM64, after the lamp check (09:51, steps 1–5), the reviewer's 09:41 and Tests' reads. Thank you, Third. lamp-4ace runs its parts already, and #1708 carries lamp-4ace's matching units.