16 Commits

Include renames

Author	SHA1	Message	Date
kevinveenbirkenbachandClaude Opus 5	791eee7c9f	refactor(mcp)!: prove the endpoint contract with a CLI test, not a deploy probe ... The contract check ran as an Ansible task in the middle of every provider deploy, and the two client checks ran the same way. A test that is part of the deploy cannot be run without deploying, cannot be re-run on its own, and reports its verdict as a deploy failure. Twenty-seven task files lose 491 lines to this. It is now what it always was. Each provider ships files/test/test.sh, templates/test.env.j2 and meta/tests.yml, and test-e2e-cli stages one shared harness beside it: run.sh drives contract.sh in a throwaway container on the provider's own network, then isolation.sh for adapter-fronted providers. The read probe each provider offers moved from the calling task into meta/mcp.yml next to the allowlist it must satisfy, and the schema now rejects a read probe naming a tool outside that allowlist. The bearer the test presents is the one a client resolves through mcp.credential, via the new mcp_client_bearer lookup over resolve_credential, which moved to utils.roles.applications.mcp so it is the same function mcp_servers renders every client connection with. The probe presented whatever the calling role passed, which for the fifteen adapter-fronted providers is a different secret than any client holds. Sidecar isolation is read from the engine rather than measured inside the container, so it no longer needs a delegation to the node holding the task: attachment is compared by network name, which drops the gwbridge special case, and a swarm worker says it cannot measure instead of skipping silently. Retrying is bounded by wall clock against MCP_DEADLINE_SECONDS, which scales through the same lookup('timeout') as the harness budget it has to stay under. A flag that is neither true nor false aborts rather than reading as off. mcp-provider-probe becomes mcp-provider-cli-test: an enabled provider must ship the test rather than include the task. mcp-probe-bearer becomes mcp-adapter-bearer, tying ADAPTER_BEARER to the declared credential key now that no probe include carries it. A new integration test renders the shared env template for every provider through Ansible's own templar, so a later change to it breaks visibly instead of poisoning twenty deploys quietly. Hermes and OpenClaw keep their client-side proof as CLI tests of their own. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-01 20:46:26 +02:00
kevinveenbirkenbachandClaude Opus 5	8d1d45d246	fix(discourse): pin the OIDC issuer for the launcher-built container ... Nextcloud#7 of run 33445831564 fails on three discourse specs, all on one assertion, all for one reason. The received body is Discourse's own page: "Sorry, there was an error while trying to authorize your account with oidc." The browser leg works. What dies is Discourse's server-side back-channel: "GET /auth/oidc/callback?...code=..." 302 2.125 2.125 "GET /auth/failure?message=openid_connect_request_failed&...&strategy=oidc" 200 Four of those, at 2.125 / 2.015 / 2.063 / 2.014 seconds. That is not the plugin's 10s HTTP timeout; it is Discourse's DNS budget, hard-coded at 2s in lib/final_destination/resolver.rb (connect_timeout arrives nil, so the default applies). openid_connect_request_failed has exactly one emitter -- omniauth_open_id_connect.rb:147-155, rescue Faraday::Error -- and the alternative, SocketError -> LookupFailedError, is not a Faraday::Error and would have produced a 500 rather than the observed 302. The correlation leaves no room: across 18 back-channel requests, all from 192.168.9.3 with UA Faraday v2.14.3, there are exactly two complete token 200 + userinfo 200 pairs -- and exactly two specs passed. Thirteen truncated flows, thirteen failures. No test that got a complete exchange failed; none that failed got one. Why discourse alone: discourse.inspect.json:72 reads "ExtraHosts": null. Grepping the whole rescue bundle for the pin finds nextcloud, nextcloud-proxy, mailu-admin, prometheus and prometheus-sso-proxy. Discourse could not have it: config.yml.j2's docker_args: carried only --network= and --name=. It is built by discourse_docker's launcher, not by a compose file, so the lookup's rendered block has nowhere to go -- hence entries_only, which returns the strings and lets the template write --add-host= lines. The pin itself is NOT re-derived: _sso_pins() and _gateway_address() stay the single place that knows compose from swarm. Its existing allowed_internal_hosts cannot help, because ssrf_detector's lookup_and_filter_ips resolves BEFORE host_bypasses_checks?; the setting only makes a private answer acceptable once it arrives. Rendered through a real Templar both ways: with SSO on, the two --add-host lines land between the networks and --name; with SSO off the output is byte-identical to today, so clearnet and variant-1 deployments render an unchanged app.yml and trigger no launcher rebuild. 24 lookup tests green. Not closed: the biber persona has never passed, here or in run 33317483326. Its failure text and code path match administrator, which did pass, so it is explained -- but a persona-specific second defect is not positively excluded. Deploying discourse variant 0 locally, which already has sso and tor enabled, settles it. Separately worth queueing: discourse's own meta/variants.yml variant 1 sets sso.enabled: false and only variant 1 is scheduled, so the role that owns these specs never runs them. Only partner rounds like Nextcloud#7 catch this class. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-01 12:00:56 +02:00
kevinveenbirkenbachandClaude Opus 5	19a8580728	fix(volumes): render a tmpfs size as the byte count compose demands ... f85996b43a turned the tmpfs options into a dict so a declaration could carry a mode as well as a size, and coerced the mode to the int docker expects. The size sitting next to it kept being copied through verbatim. The short form accepts "512m" and so does a human writing the declaration; the long form this renders takes an integer and refuses the string rather than parsing it: services.checkmk.volumes.1.tmpfs.size must be a integer That is the whole of Checkmk#0 in run 33317483326, and it stops the deploy before the role does anything. The suffix is resolved the way the mode already was, in a helper beside it, and a value that is neither an int nor a byte count is refused instead of passed on -- passing it on is what let "512m" reach compose in the first place. The existing test asserted {"size": "64m"}, so it pinned the defect: the suite stayed green while CI failed on it. It now asserts the byte count, every unit a declaration may write resolves, and three malformed sizes raise. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-31 01:17:54 +02:00
kevinveenbirkenbachandClaude Opus 5	d7de6e3805	fix(compose_volumes): leave the two-engine diagnostic to its owner ... b067d21ef added the realignment helper as an argument to compose_volumes(), so it now runs before that function reaches its own guarded call. A role with both engines enabled therefore raised the bare ValueError through the lookup, and the message that names the collision and says to pick one dbtype per role had become unreachable. The helper catches it and defers. No role can trigger this today: over all 265 meta/services.yml, none declares both keys at all, and `enabled` has a single shape across the tree, the literal True in 54 places. The guard protects the diagnostic for whoever adds the second engine, which is exactly when a bare ValueError would be least useful. The tests pin what the two startup failures cost to find. The SQL must stay one ALTER USER IF EXISTS: root must not appear, because giving it a password during the entrypoint's temporary server breaks a readiness probe that connects without one; CREATE USER must not appear, because the entrypoint's own carries no IF NOT EXISTS and the script runs under set -e; and the GRANT must not come back, because rotating a credential changes passwords, not privileges. Verified by rendering the version those tests were written against: it puts root, CREATE USER and GRANT in the file and four statements in place of one, so every assertion fails on it. The deferral was checked the same way, against the module as it stands in HEAD. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-30 13:56:51 +02:00
kevinveenbirkenbachandClaude Opus 5	52b4504035	fix(container-dns): let the bridge be declared instead of guessed ... Whether a resolver answers on the docker bridge was inferred from the host's own resolv.conf: all entries loopback was read as "a listener of ours is there, and containers must reach it on the bridge". A systemd-resolved stub binds 127.0.0.53, NetworkManager's dnsmasq binds 127.0.0.1, and a node dnsmasq binds both those and the bridge. All three look identical from resolv.conf and only the third is reachable from a container. So ordinary hosts were handed an address with nothing behind it. The Instructions job died there: daemon.json carried "dns": ["10.208.0.1"] alone, and the openresty build could not resolve dl-cdn.alpinelinux.org while the daemon, resolving through the host, pulled the same base image fine. Two netns, two outcomes. e308e18923 had already fixed this once, with a reachability gate whose message names the same URL. b09f2cbd82 dropped that gate and ce43263745 put the resolv.conf inference in its place, so the guard was gone and only the missing docker0 fact still hid it. 285ba1e76c removed that accident and the failure surfaced. svc-net-tor and NETWORK_CONTAINER_BRIDGE_RESOLVER now say it instead, the latter false by default and true in the swarm lab, which provisions the dnsmasq its nodes resolve through. Extra-vars are global, so the lab's NFS and backup hosts carry it although no listener is installed there; the clearnet resolver behind the bridge keeps them working. The docker0 fact is gone from the address too. It is not merely late, it is wrong while it is late: facts are read before the daemon config is applied, so docker0 still holds docker's default and writing default-address-pools moves the bridge out from under it. A swarm node shipped "dns": ["172.17.0.1", ...] against a live 10.208.0.1, which is why its containers asked a dead address and fell through to the public resolver, where infinito.example does not exist. The pool answers before the daemon exists and answers the same afterwards, and it is read per slice rather than per supernet, which differ once a pool does not start on a slice boundary. A list that would carry only the bridge now gets NETWORK_PUBLIC_DNS_RESOLVERS behind it, so a declaration that turns out to be wrong costs a wasted first query rather than all name resolution. An empty declaration raises. Rendered from the repository's own variable files: the Instructions host yields [] and the template omits the key, which is what de95a95c65 emitted while that job was green; lab and tor nodes yield the live bridge ahead of the clearnet resolver even with a stale docker0 fact present; an ordinary host yields only its declared resolver. The suite asserted the two behaviours this replaces, including one case added with 285ba1e76c demanding the stale fact win. They are inverted, and a cross-product over nameserver shapes, tor membership, clearnet and the docker0 fact now asserts that no shape ends up holding the bridge alone - the old suite checked each shape by itself, which is how this passed through it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-30 00:32:13 +02:00
kevinveenbirkenbachandClaude Opus 5	285ba1e76c	fix(container-dns): take the bridge from the pool, not from a fact ... ce43263745 replaced the bridge literal with the clearnet resolver and left the lookup to supply the bridge from ansible_facts.docker0. That fact cannot be there on the run that needs it: facts are gathered at play start, nothing in the role re-gathers them, and on a fresh node docker is installed afterwards - so the render that writes daemon.json always sees no docker0 and emits the clearnet resolver alone. Measured on one node of the same job: docker0 is 10.208.0.1/24 while its /etc/docker/daemon.json carries "dns": ["1.1.1.1"]. The bridge existed and was missing from the config that had to name it. The inner containers then asked a public resolver for a name only the node dnsmasq serves, and the DinD check reported it accurately seven times: Server: 1.1.1.1 ** server can't find infinito.example: NXDOMAIN (The '[container] CA trust certificate is not a regular file' line above it is noise - container.py catches that and falls back to plain docker run.) default-address-pools is where docker takes docker0 from, so the declaration answers before the daemon exists and gives the same answer after: subnet_gateway("10.208.0.0/12") is the 10.208.0.1 measured above. An observed docker0 still wins, so a host whose bridge sits elsewhere keeps its real address. That also settles what the docstring flagged as unavoidable. The fact-derived value appeared only from the second run on, so daemon.json differed between passes and restarted the container runtime under a live stack. Both passes now render the same bytes. Only the swarm path showed it: 18 jobs died at the daemon start before reaching this handler, and the six that got here in the next run are the first to exercise it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-29 22:08:51 +02:00
kevinveenbirkenbachandClaude Opus 5	8e3fe04d72	fix(mcp): read a provider's bearer where provisioning writes it ... Discovery resolved applications[role].credentials, the address from before f713ba8350 moved every credential under secrets.credentials. The run's own inventory shows which one is real: twelve applications carry secrets.credentials, none carries the top-level key. So every provider declaring credential.source: credentials - fifteen of the twenty - handed back an empty mapping, and reconciliation aborted on a secret that had been provisioned all along: mcp_servers: 1 authorized MCP server(s) cannot be rendered. web-app-prometheus: credential_missing: web-app-prometheus declares owner 'mcp-web-app-prometheus' but no secret resolved The five providers on token_store read through users and were never affected, which is why only some clients broke. Provider and client were reading the same secret at two addresses: web-app-prometheus/vars/main.yml:32 renders its bearer from secrets.credentials.mcp_bearer. Without the strict assert this would have surfaced as a 401 at runtime rather than a failed deploy. The lookup was correct when 6881ac5132 wrote it - the rename landed on a branch it was not an ancestor of, and arrived here through the main merges of 08-15. Its own message notes that no regex over lookup('config') could see an access path like this one; a .get("credentials") split across two lines in a Python plugin is equally invisible to it. The address now comes from credential_key's constants, which is where the module already claims a credential is addressed by exactly one string. resolve_credential was always handed a fabricated mapping directly, so the function was covered and its caller's address was not. The new tests close that seam, one of them end to end over the shape provisioning produces. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-29 20:57:07 +02:00
kevinveenbirkenbachandClaude Opus 5	f4b1ccadd7	fix(container-dns): re-tag the value before handing it to the templar ... 5345f1632 added the render step but not the re-trust, so it never worked. ansible-core 2.19+ renders only strings carrying TrustedAsTemplate, and the str() coercion on the line above drops the tag the extra-vars loader attached. templar.template() then hands the expression back untouched, the guard sees Jinja and raises: The lookup plugin 'container_dns' failed: networks.internet.dns is '{{ NETWORK_PUBLIC_DNS_RESOLVERS | first }}' and did not resolve to an address. Which is worse than the ParseAddr the guard was written to prevent, and on the same 18 jobs: before, one bad daemon.json; after, every run that reaches the daemon config, compose included, since inventories/development/default.yml carries a lookup('env') there. Re-tagging first is what proxy_pass, container_ports, container_volumes and compose_volumes already do. Through the real lookup loader the field now renders to ["10.208.0.1", "1.1.1.1"]. The unit stub was the reason none of this showed: it rendered any string, so twenty tests passed against code that could not work in a play. It now refuses an untagged string the way the templar does, which makes the four tests covering this fail without the re-trust. Stub and production key off the same private ansible module, so a move would degrade both at once - production to silent identity, the stub to rendering anything. The added class asserts that shared premise rather than trusting it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-29 20:55:46 +02:00
kevinveenbirkenbach	5345f1632e	fix(container-dns): render the inventory value before docker reads it ... ce43263745 replaced the literal 172.17.0.1 under networks.internet.dns with {{ NETWORK_PUBLIC_DNS_RESOLVERS | first }}, for a good reason: the fixed address went stale whenever default-address-pools moved the bridge. Nothing renders that field, though. The file arrives as '-e @inventories/development/swarm.yml' and this lookup read it straight out of variables, so the expression reached the daemon as its own source text: dockerd: unable to configure the Docker daemon with file /etc/docker/daemon.json: invalid JSON: ParseAddr("{{ NETWORK_PUBLIC_DNS_RESOLVERS | first }}"): unable to parse IP Then 'Start request repeated too quickly', and the node has no container engine, which is where eight swarm jobs died - across centos and debian, so it was never distro-specific. While the field held an address the missing render step was invisible. It now renders against the lookup's own templar, and refuses to emit a value that still carries Jinja. A string that is not an address has no business in daemon.json, and failing loudly beats leaving a node without docker.	2026-08-29 19:42:47 +02:00
kevinveenbirkenbach	c04c49e753	refactor(mcp): drop the path-addressed endpoint from client discovery ... Baserow was the only role declaring endpoint.key_credential, and putting the adapter in front of it left the field with no consumer. Keeping it would also contradict the decision that put the adapter there: a secret in the URL path cannot be scoped per consumer and cannot be revoked on its own, so a provider authenticating that way belongs behind an adapter rather than in a client's rendered configuration. The segment now stays between the adapter and its upstream. Discovery loses a config lookup per provider per client along with the branch. The test that proved the segment was appended becomes its inverse: an endpoint still declaring the field gets a URL without one, so the decision is held rather than merely unproven.	2026-08-29 10:55:34 +02:00
kevinveenbirkenbachandClaude Opus 5	f52315850c	test(openwebui): pin what a bare restart brings back ... Open WebUI runs with persistent config off, so the environment is authoritative on every start and whatever the connection filter renders is the state the container comes back with, not only what a deploy produces. The filter already carried the group grant in that environment, but nothing asserted it: without the grant travelling there, a restart would restore a disabled connection that waits for the next deploy. The README described exactly that outage as the current behaviour, which stopped being true once the grant moved into the environment, so it is corrected rather than left to mislead the next reader. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-29 00:55:22 +02:00
kevinveenbirkenbachandClaude Opus 5	ce29195b64	fix(qdrant,flowise): authenticate the vector engine and prove what Flowise can reach ... Qdrant ran with no authentication at all: its environment set the HTTP port and disabled telemetry and nothing else, so every container that reached its network held full read, write and delete access to every collection, and the MCP surface's read-only promise rested entirely on the adapter's contract naming only GET routes. Qdrant 1.19 forces authentication on every request once a read-only key is set, so the engine now declares both keys, the adapter presents the read-only one, and the full key goes only to consumers that own data here. A write route is now refused by the engine rather than only by the adapter. Three defects in the Flowise registry path. Its tool-name check compared against a contract the role always passed as empty, so it could not fail; it now compares against the provider's declared allowlist. Its managed flow pointed a customMCP node at an input that exists on no node at this tag, while the node that does take a registry id is customMcpServerTool, and the one that takes an inline config would have embedded the bearer in the flow; the flow is now an Agentflow whose Tool node calls one named tool with fixed arguments and is executed on every deploy. Its module docstring claimed only SSE providers could be registered, while the pinned MCPToolkit connects Streamable HTTP first and falls back to SSE, so the docstring contradicted the role's own declaration. Reaching a provider inside the container network needs HTTP_SECURITY_CHECK=false, which replaces the built-in deny list rather than merging into it, so a typo there disables every protection silently while the registry keeps working. The deploy now points a throwaway entry at loopback and at the metadata address and fails unless both are refused. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-29 00:49:58 +02:00
kevinveenbirkenbachandClaude Opus 5	ce43263745	fix(container-dns): follow the live bridge, not a configured address ... The swarm inventory carried the manager's docker bridge gateway as a literal under networks.internet.dns, so one field meant two things at once and the value went stale the moment default-address-pools moved the bridge. The daemon kept handing out the new address while the inventory kept naming the old one, and the DinD diagnostic probed that same literal, so it failed in step with the defect instead of catching it. The inventory now declares only the clearnet resolver. The lookup hands containers the bridge whenever the host resolves solely through a loopback listener, which is how the simulated cluster nodes are wired and which docker strips from a container's resolv.conf. The diagnostic reads the gateway from the running daemon instead of being told it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-29 00:06:42 +02:00
kevinveenbirkenbachandClaude Opus 5	7162b7bf4c	Merge fork/feature/svc-net-tor into feature/ai-agent-employees ... 834 commits from the Tor onion-service branch against 299 of ours, from merge base 7b646bdece: 127 conflicted files, 3506 files changed. The two sides are largely orthogonal. Theirs adds svc-net-tor and a `tor` service across the role tree, plus two sweeping refactors: shipped scripts sorted by language (files/ruby/, files/python/, files/shell/, scripts/lint/*.sh) and the unit suite moved under tests/unit/python/. Ours is requirement 036, the native AI gateway, plus the MCP role work. Most conflicts were both sides appending to the same service map, resolved as unions. Resolutions that were not unions: Credentials moved namespace. Theirs renamed meta/schema.yml to meta/secrets.yml and re-addressed credentials as secrets.credentials.<name>. Git carried our litellm_api_key blocks through the rename, but every consumer we added still read 'credentials.<name>', which no longer resolves. All 45 call sites are migrated. plugins/filter/container_volumes.py is deleted by theirs and relocated to plugins/lookup/container_volumes.py, where it carries the same tmpfs defect our f85996b43 had just fixed: a hard-coded {"size": ...} that silently drops a per mount `mode`. The fix is re-applied in the relocated file, as that commit's merge note anticipated. compose.yml keeps only INFINITO_PLAYWRIGHT_REPORTS_BASE_DIR. Theirs also forwards INFINITO_PLAYWRIGHT_STAGE_BASE_DIR; that line is deliberately dropped, per the analysis recorded in 45804e9ad -- STAGE has a drift-proof role-vars fallback, while forwarding it promotes a setdefault-pinnable .env value above that SPOT. tasks/stages/01_constructor.yml takes their include, ./tasks/utils/setup/group.yml, because their refactor removed tasks/groups/*-roles.yml, leaving our include target nonexistent. Our task name is kept, since svc-virt is in the loop. Makefile swarm-zombie is a union: their validate plus teardown, then our lab_subnet cleanup, which their side dropped while leaving lab_subnet.sh as the only orphaned reference in the file. 01_bootstrap.sh keeps our deterministic --ip pinning, which distinguishes an already-attached node from a real failure, over their `|| true`. Their language-sorted layout orphaned references our side still held: zammad's two scripts/apply/*.rb, jenkins' java-with-ca-trust.sh, and the notify topics their handlers renamed to hyphenated form. All corrected. roles/sys-svc-compose/files/shell/swarm/stack_ready.sh gains our latched-update block: paused, rollback_paused, rollback_started and rollback_completed exit 2 rather than polling a state that cannot resolve without another deploy. config_from_run is unioned to (title, logged, jobs); the production caller in trigger/__main__.py now passes jobs, without which our suite suppression would have been inert. READMEs are regenerated rather than hand-merged: 15 LiteLLM rows and 91 Tor rows now derive from the merged metadata, which is itself evidence the meta merge is coherent. Verified: 5161 unit tests pass. The single failure, test_query.py TestSortSpec, also fails on fork/feature/svc-net-tor at b51d2f9919, measured in a baseline worktree -- so this merge introduces no new unit-test failure. Two modules are excluded from that run because `baudolo`, a dependency their branch introduces, is not installed on this host. Not verified: no deploy has run against the merged tree, and make quality has not been run end to end here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-24 16:32:30 +02:00
kevinveenbirkenbach	9b78933153	refactor(env): group the CA handlers into their own subpackage ... The two ca_* handlers sat flat in utils/env/handlers/infinito, which the prefix-grouping lint rejects, and the bundle-candidates comment exceeded the .env comment length limit.	2026-08-22 20:24:53 +02:00
kevinveenbirkenbachandClaude Opus 5	575a5a87ac	refactor(layout): sort shipped scripts by language and split the unit suite ... Every script a role ships now lives under `files/<language>/`, and the unit suite is split the same way: `tests/unit/python/` beside new sibling trees for the other languages. `tests/lint/filesystem/test_role_files_layout.py` keeps it that way; directories whose shape is dictated from outside carry a `.nocheck` naming the constraint (Docker build contexts, WordPress mu-plugins, the Joomla extension, Odoo addons, Playwright suites, the `files/test/test.sh` harness that `test-e2e-cli` resolves generically). This cannot be applied in halves. Moving a file and repointing what names it are the same change: 14 references resolve only at deploy time, so the tree is green either before or after, never between. Those 14 were found by static resolution over every reference class, not by the test suite -- a full `make quality-high` was green while all of them were broken: * 7 `src:` values built from a role variable holding a bare filename (svc-bkp-remote-2-local, decidim, espocrm, friendica, joomla, pixelfed x2). The variable doubles as the destination name inside the container, so the language segment belongs at the call site, not in the variable. * `sys-service/tasks/04_base.yml` resolved every consumer's systemd script through `first_found(..., errors='strict')` over `files/script.{sh,py}`. 18 roles ship exactly that and have no template fallback: the play would have died on each. * `sys-front-inj-javascript` fell back to `<role>/files/javascript.js`; the interface now reads `files/javascript/javascript.js`. * `sys-front-inj-logout/templates/head_sub.j2` built the cache-busting mtime path through `path_absolute(... 'files', ...)`. * 4 `ansible.builtin.script:` invocations naming a bare command (pull.py, prune.sh, set_postgres_superuser_password.sh, ganesha-serve.sh). * `dev-python/files/shell/install.sh` pointed at a sibling role's script. Depth-dependent paths inside the moved trees were bumped accordingly: 59 `parents[N]` computations, 12 relative climbs, and the per-role recover CLI, whose path `cli/administration/recover/recoverers.py` still assembled from the pre-move location. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-22 01:31:09 +02:00