Trim tangled-knot to host substrate only after the deploy surface exists #504

New issue

Open

opened 2026-07-09 21:24:17 +00:00 by coilyco-ops · 1 comment

coilyco-ops commented

2026-07-09 21:24:17 +00:00

Member

Summary

After coilyco-bridge/deploy gains a real services/tangled-knot/ surface, remove the remaining deploy-ish tangled-knot files from infrastructure and leave only the host substrate.

This issue is downstream of the deploy repo work. Do not land the cleanup until the deploy repo owns the replacement files and the live host paths / systemd ExecStarts have been updated accordingly.

Why

The intended split from coilyco-bridge/deploy#117 is:

Infrastructure owns host substrate only.
Deploy owns public exposure and service/deploy behavior.

Infrastructure currently owns both categories.

The substrate pieces that should remain here are the host-native runtime foundation:

systemd/tangled-knot.service
systemd/tangled-knot.env while the knot remains host-native
scripts/install-tangled-knot.sh
scripts/tangled-knot-keyfetch.sh
sshd/tangled-knot.conf
any privileged bootstrap around /etc/tangled-knot, /opt/tangled-knot, /var/lib/tangled-knot, the git OS user, and sshd reload

The deploy-owned pieces should leave this repo once deploy has adopted them.

Scope

After the deploy issue lands:

remove or relocate the deploy-owned files from infrastructure:
- deploy/tangled-knot-ingress.yml
- scripts/coilysiren-tangled-knot-autodeploy.sh
- scripts/install-coilysiren-tangled-knot-autodeploy.sh
- systemd/coilysiren-tangled-knot-autodeploy.{service,timer}
- scripts/coilysiren-tangled-knot-mirror.sh
- scripts/install-coilysiren-tangled-knot-mirror.sh
- systemd/coilysiren-tangled-knot-mirror.{service,timer}
update infra docs so they explicitly describe the remaining boundary
- docs/FEATURES.md if needed
- any knot-related host docs
- comments in caddy/Caddyfile or other references that still point at infra-owned deploy manifests

Migration caution

This cleanup is risky if done in the wrong order because the live unit files currently point into the infrastructure checkout path.

Before deleting anything here, verify that:

the replacement files exist in coilyco-bridge/deploy
installed unit files on kai-server have been updated to the new paths, if they still exist as host units
no key material or manual DID registration step is being accidentally regenerated

Open question

If the service-specific autodeploy / mirror timers continue to run as host systemd units, decide whether infrastructure keeps only a generic systemd-management mechanism while the tangled-knot-specific unit contents live in deploy, or whether the units are run/installed entirely from deploy conventions. The recommended direction is to keep infrastructure generic and move service-specific ownership out.

Done condition

Infrastructure no longer owns tangled-knot's public ingress or service rollout behavior.
Infrastructure documents and ships only the host-native substrate needed to run the daemon safely.
Docs in both repos make the ownership line obvious.

Filed by ward agent advisor cross-repo fan-out from coilyco-bridge/deploy#117 (part 2 of 2, ward#424). Upstream dependency: coilyco-bridge/deploy#118.

— Codex, via ward agent

## Summary After `coilyco-bridge/deploy` gains a real `services/tangled-knot/` surface, remove the remaining **deploy-ish** tangled-knot files from infrastructure and leave only the host substrate. This issue is **downstream of** the deploy repo work. Do not land the cleanup until the deploy repo owns the replacement files and the live host paths / systemd ExecStarts have been updated accordingly. ## Why The intended split from `coilyco-bridge/deploy#117` is: - **Infrastructure** owns host substrate only. - **Deploy** owns public exposure and service/deploy behavior. Infrastructure currently owns both categories. The substrate pieces that should remain here are the host-native runtime foundation: - `systemd/tangled-knot.service` - `systemd/tangled-knot.env` while the knot remains host-native - `scripts/install-tangled-knot.sh` - `scripts/tangled-knot-keyfetch.sh` - `sshd/tangled-knot.conf` - any privileged bootstrap around `/etc/tangled-knot`, `/opt/tangled-knot`, `/var/lib/tangled-knot`, the `git` OS user, and sshd reload The deploy-owned pieces should leave this repo once `deploy` has adopted them. ## Scope After the deploy issue lands: - remove or relocate the deploy-owned files from infrastructure: - `deploy/tangled-knot-ingress.yml` - `scripts/coilysiren-tangled-knot-autodeploy.sh` - `scripts/install-coilysiren-tangled-knot-autodeploy.sh` - `systemd/coilysiren-tangled-knot-autodeploy.{service,timer}` - `scripts/coilysiren-tangled-knot-mirror.sh` - `scripts/install-coilysiren-tangled-knot-mirror.sh` - `systemd/coilysiren-tangled-knot-mirror.{service,timer}` - update infra docs so they explicitly describe the remaining boundary - `docs/FEATURES.md` if needed - any knot-related host docs - comments in `caddy/Caddyfile` or other references that still point at infra-owned deploy manifests ## Migration caution This cleanup is risky if done in the wrong order because the live unit files currently point into the infrastructure checkout path. Before deleting anything here, verify that: - the replacement files exist in `coilyco-bridge/deploy` - installed unit files on kai-server have been updated to the new paths, if they still exist as host units - no key material or manual DID registration step is being accidentally regenerated ## Open question If the service-specific autodeploy / mirror timers continue to run as host systemd units, decide whether infrastructure keeps only a **generic systemd-management mechanism** while the tangled-knot-specific unit contents live in deploy, or whether the units are run/installed entirely from deploy conventions. The recommended direction is to keep infrastructure generic and move service-specific ownership out. ## Done condition - Infrastructure no longer owns tangled-knot's public ingress or service rollout behavior. - Infrastructure documents and ships only the host-native substrate needed to run the daemon safely. - Docs in both repos make the ownership line obvious. --- Filed by `ward agent advisor` cross-repo fan-out from coilyco-bridge/deploy#117 (part 2 of 2, ward#424). Upstream dependency: coilyco-bridge/deploy#118.  — Codex, via `ward agent`

coilyco-ops added the

consult

labels

2026-07-09 21:46:08 +00:00

coilyco-ops added

and removed

labels

2026-07-10 08:59:51 +00:00

coilyco-ops commented

2026-07-10 12:22:28 +00:00

Author

Member

🔎 ward agent advisor

ward agent advisor --harness codex ran a one-shot standard research pass on this question:

Read the issue title, body, and comment thread below as the research brief. Identify the decisions, options, open questions, and risks, then give a clear advisory recommendation that can be posted back on the issue.

pre-commit installed at .git/hooks/pre-commit
pre-commit installed at .git/hooks/commit-msg

Researched and posted automatically by ward agent advisor --harness codex (ward#179). This is one-shot research, not a carried change - verify before acting on it.

— Codex, via ward agent

### 🔎 ward agent advisor `ward agent advisor --harness codex` ran a one-shot **standard** research pass on this question: > Read the issue title, body, and comment thread below as the research brief. Identify the decisions, options, open questions, and risks, then give a clear advisory recommendation that can be posted back on the issue. --- pre-commit installed at .git/hooks/pre-commit pre-commit installed at .git/hooks/commit-msg --- Researched and posted automatically by `ward agent advisor --harness codex` (ward#179). This is one-shot research, not a carried change - verify before acting on it.   — Codex, via `ward agent`