spec: the lock paragraph no longer says a queued pass stepped aside
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
1 file changed,
+4
−4
docs/superpowers/specs/2026-09-07-named-unit-config-delivery-design.md+4 −4
CI passed — run details
diff --git a/docs/superpowers/specs/2026-09-07-named-unit-config-delivery-design.md b/docs/superpowers/specs/2026-09-07-named-unit-config-delivery-design.md| index 35902b8df..fa5f40b62 100644 |
| --- a/docs/superpowers/specs/2026-09-07-named-unit-config-delivery-design.md |
| +++ b/docs/superpowers/specs/2026-09-07-named-unit-config-delivery-design.md |
| @@ -309,10 +309,10 @@ drop-in carries a path, not a secret. |
| exclusive flock on `<envDir>/.sync.lock` for its whole run, the shape |
| `restartPass` already has, and blocks until the other pass releases it, so |
| the two passes queue rather than interleave; only a lock file that cannot |
| -be opened makes the pass print and return without touching anything; the |
| -hourly `carlos-adopt.service` and the triggered `carlos-config-sync.service` |
| -therefore never interleave inside a config transaction, and the next |
| -trigger or timer runs the pass that stepped aside. No unit file changes. |
| +be opened makes the pass print and return without touching anything, and |
| +the next trigger or timer retries it. The hourly `carlos-adopt.service` |
| +and the triggered `carlos-config-sync.service` therefore never interleave |
| +inside a config transaction. No unit file changes. |
| **(decision)** Application is tracked separately from file content, and |
| authorised only by successful preparation (codex R1-4, R2-2, R2-4). |