Background
PR #103 introduces `.conoha-mode` as a server-side source of truth for dispatch. Concurrent CLI invocations against the same app + server pair can produce inconsistent state:
- `conoha app destroy` reads marker, starts running `rm -rf`.
- `conoha app deploy --no-proxy --app-name X` reads marker (still present or ErrNoMarker depending on timing), uploads tar, runs compose up.
- End state: live compose project with no marker. Next `logs`/`stop` calls fail with "has not been initialized".
Not a data-loss scenario, but a confusing recovery path. Fixable by the user re-running `app init`.
Scope
No code change proposed — the single-operator assumption is the right default. This issue is a docs-only update to spec §12 ("オープンな技術判断") so the TOCTOU window is explicitly acknowledged, with guidance that destructive operations should not be run in parallel against the same app.
Pointer
- `docs/superpowers/specs/2026-04-21-no-proxy-mode-design.md` §12
Surfaced by review on PR #103 (item M6).
Background
PR #103 introduces `.conoha-mode` as a server-side source of truth for dispatch. Concurrent CLI invocations against the same app + server pair can produce inconsistent state:
Not a data-loss scenario, but a confusing recovery path. Fixable by the user re-running `app init`.
Scope
No code change proposed — the single-operator assumption is the right default. This issue is a docs-only update to spec §12 ("オープンな技術判断") so the TOCTOU window is explicitly acknowledged, with guidance that destructive operations should not be run in parallel against the same app.
Pointer
Surfaced by review on PR #103 (item M6).