refactor: rename posture to source mode (workspace | owned) - #331
Merged
Conversation
`--posture engineering|managed` reads as a level, as though engineering
were the unrestricted one and managed the safe one. It is not a level, and
it is backwards: engineering is strictly MORE restricted on live source,
where the installed tree is read-only reference. What it buys is git and
review, not latitude.
The new names say where a change LANDS, which is the actual difference:
workspace installed source is read-only reference; changes go through a
Data Machine Code workspace, git, and GitHub. Recorded by review.
owned the agent edits the site's declared components in place; no
workspace, no git, no GitHub. Recorded by the operator's
out-of-band capture.
Neither implies rank, which is the whole point.
#324 also asks for a third `unchained` shape. Not added: that decision
already went the other way — capability correlates with the mode, the
dev-toolchain/server-admin line is not enforceable in a shell (npm,
composer, and git hooks all execute arbitrary code), and nobody wants the
combination it would carve out. Renaming does not depend on it.
The default is deliberately unchanged. `workspace` is exactly today's
`engineering`, so no install changes behaviour. #324 additionally proposes
making the owned mode the default; that is a product decision about what a
fresh install should get, it is separable from the rename, and bundling
them would make both harder to review and to revert.
Existing installs carry across without the operator touching anything:
- `--posture` remains an accepted alias, and engineering/managed are
translated wherever a mode is read, including in the Python reconciler,
which is reachable directly and has to agree with the shell.
- The three recorded wp_options are renamed, and reads fall back to the
pre-rename keys. Deliberately a fallback rather than a one-shot upgrade
migration: a newer upgrade.sh can meet an older install's options at any
time, and `wp option get` returning empty is indistinguishable from
"recorded as empty".
- record_mode compares against the NEW key only. Comparing through the
legacy-aware reader would see a pre-rename install as already correct —
the canonical value of `engineering` IS `workspace` — and leave it on the
old key forever, so the migration would never actually run.
Verified the rename changes no behaviour, which is the only property that
matters here: the reconciler's output and a fully rendered opencode.json
are both byte-identical to origin/main across all four combinations
(old engineering vs new workspace, old managed vs new owned, and new code
fed the legacy names). Checked against the live install too — it records
`engineering` under the old key and resolves to `workspace`, read-only.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #324 (naming). Does not add the third
unchainedshape — see below.The problem
--posture engineering|managedreads as a level. It is not one, and it is backwards:engineeringis strictly more restricted on live source, since the installed tree is read-only reference there. What it buys is git and review, not latitude.The new names say where a change lands, which is the actual difference:
workspace(default)ownedNeither implies rank. That's the point.
What this deliberately does not do
No third
unchainedmode. That decision already went the other way: capability correlates with the mode, the dev-toolchain/server-admin line isn't enforceable in a shell (npm, composer, and git hooks all execute arbitrary code), and nobody wants the combination it carves out. The rename doesn't depend on it.No default change.
workspaceis exactly today'sengineering, so no install changes behaviour. #324 also proposes making the owned mode the default — that's a product decision about what a fresh install should get, it's separable, and bundling it would make both harder to review and to revert. Flagging it as still open.Existing installs carry across untouched
--posturestays an accepted alias;engineering/managedare translated wherever a mode is read — including in the Python reconciler, which is reachable directly and has to agree with the shell.wp_optionsare renamed, and reads fall back to the pre-rename keys. Deliberately a fallback rather than a one-shot migration: a newerupgrade.shcan meet an older install's options at any time, andwp option getreturning empty is indistinguishable from "recorded as empty".record_modecompares against the new key only. Comparing through the legacy-aware reader would see a pre-rename install as already correct — the canonical value ofengineeringisworkspace— and leave it on the old key forever, so the migration would never actually run.Evidence the rename changed nothing
The only property that matters for a rename. Both the reconciler's output and a fully rendered
opencode.jsonare byte-identical toorigin/mainacross all four combinations:Also checked against the live install: it records
engineeringunder the old key and resolves toworkspace. Read-only, no writes.New coverage in
tests/source-mode.sh(renamed fromposture.sh) pins the alias translation, legacy-key resolution on upgrade, that the migration actually writes the new key, and that it doesn't rewrite an already-migrated install.Full suite green apart from the 3 pre-existing environmental failures that also fail on
origin/main.