feat(store): store Configs with CLI and SDK access#1417

_{P1 Badge} Define Config in the domain glossary

These public types introduce Config as a new capitalized domain concept and assert that it is owned by an Environment, but core/CONTEXT.md currently defines Environment content only in terms of Services and Volumes and gives Config no meaning or lifecycle. Define Config and its relationship to Environment in the glossary before establishing these shared contract types, so later storage, CLI, and deployment work does not build on conflicting semantics.

AGENTS.md reference: AGENTS.md:L7-L7

Useful? React with 👍 / 👎.

Fixed in 8e4efa167. core/CONTEXT.md now defines Config and Config Mount, and says how each relates to an Environment.

_{P2 Badge} Compare canonical effective mount targets

This collision check only canonicalizes trailing slashes and only collects Config file paths. Consequently, two Config mounts such as /etc and /etc/. containing the same filename are accepted even though they resolve to the same Linux target; likewise, a Volume mounted at /etc/app.yml is accepted alongside file app.yml from a Config mounted at /etc. This permits invalid Working State that will produce duplicate effective mount destinations, so build one canonical target set containing both expanded Config files and Volume mounts before admitting the document.

Useful? React with 👍 / 👎.

Fixed. /etc/.-style aliases are refused by 9e87cb8ab, which accepts only canonical mount directories. A Volume mounted at or under a Config file's path is refused by 9194c1316, which has tests in environment_intent.rs.

_{P1 Badge} Advance Config nodes after successful deployments

After any successful deployment, this predicate still evaluates against an empty Config collection: deployments freeze only TargetNode::Service and TargetNode::Volume, and deployment::lifecycle::advance consequently inserts only Service and Volume rows into config_applied. Therefore Config listings remain deployed: false, reviews continue treating deployed Configs as new, and a staged deletion disappears from the listing instead of being compared with its deployed version. Configs need to be included in Applied State when the deployment that carries them advances.

Useful? React with 👍 / 👎.

Intended for this PR. Configs don't reach Applied State until they deploy, which is the next PR in the stack. Until then config ls shows every Config as a create. The PR body lists this under Scope.

_{P1 Badge} Preserve Config snapshots during deployment lowering

When a Service mounts a Config, this arm discards the only snapshot containing the Config's files. The resulting ServiceConfig mount metadata is also ignored by lower_deployment, which destructures only settings and mounts and builds only a volume graph, so the Deploy Intent contains neither ConfigSpecs nor Config mounts. Such a deployment can report success while the container receives none of the configured files; convert the Config snapshots and Service attachment metadata into the runtime config graph instead of dropping them.

Useful? React with 👍 / 👎.

Intended for this PR. Configs are stored here but don't deploy yet. history::as_deployed strips Config mounts from what a Deployment runs, so Applied State never points at a Config it doesn't carry. Lowering Configs into the runtime config graph is the next PR in the stack.

_{P1 Badge} Align the Config snapshot assertion with its wire shape

The new configs_compile_with_references_written_by_service_name test fails unconditionally: the serialized value is a ValuePart array, while this assertion expects rendered text. ConfigNodeConfig and the generated SDK contract both currently declare each file as SavedConfigFile, whose content is Array<ValuePart>. Update the assertion to validate that structured representation, or change the implementation and generated contract consistently if compiled snapshots are intended to contain text, so this test does not leave the suite red.

Useful? React with 👍 / 👎.

Stale. The test was rewritten as configs_compile_with_references_kept_by_service_lineage, which asserts the ValuePart array, and it passes.

_{P2 Badge} Allow restoring individual Config changes

When a Config name or file is changed alongside another file, the review builds paths such as configs.NAME.name and configs.NAME.files.PATH, then uses this parser to determine can_restore. Rejecting every Config path containing another dot marks all those rows non-restorable, so ployz discard can only reset the whole Config and unintentionally discard unrelated edits. Parse the Config's name/file subpaths and route them to field-level restoration.

Useful? React with 👍 / 👎.

Not in this PR. Every Config is a create until Configs deploy, so a file or name row has no baseline to restore, and configs.NAME is the only meaningful discard. Per-file restore needs Applied Configs, so it ships with deployment in the next PR.

_{P1 Badge} Add user documentation for the Config commands

This introduces the user-facing ployz config command family, including creation, file management, mounting, inspection, and deletion, but the commit changes no file under docs/user/; the current user documentation therefore does not explain the new workflow, file constraints, reference syntax, or mount semantics. Add the shipped behavior to the relevant guide and documentation navigation.

AGENTS.md reference: AGENTS.md:L6-L6

Useful? React with 👍 / 👎.

Deferred by plan. User docs for Configs (docs/user/services/configs.md) ship in the stack PR that makes Configs deploy and appear in the dashboard. Documenting a command whose files never reach a container would describe behavior users can't use yet.

_{P1 Badge} Keep legacy configs Services addressable

On an upgraded store containing a Service named configs—valid before this commit because only volumes was reserved—every path such as configs.replicas is now captured as the Config namespace, while the bare configs path is rejected above. Settings queries and edits, discard, and other path-based operations can therefore no longer address that persisted Service; preserve a legacy/escaped resolution or migrate these names before reserving the namespace.

AGENTS.md reference: AGENTS.md:L5-L5

Useful? React with 👍 / 👎.

Accepted tradeoff, the same one taken when volumes was reserved. A Service named configs can still be renamed with ployz service rename, because RenameService takes a Service name, not a setting path. After that, path addressing works again.

_{P2 Badge} Bump the catalog version for the new Config setting

Adding the published SERVICE.configs.CONFIG path changes the catalog schema, but CATALOG_VERSION remains 1 despite this file's requirement to bump it whenever a published path, type, or meaning changes. Consumers using x-ployz-version therefore cannot distinguish the old catalog from one containing Config mounts; increment the version alongside this schema addition.

Useful? React with 👍 / 👎.

Not bumping. The version marks a change to an existing published path, type or meaning, and adding a path changes none of them. Commit 98a0e6a42 added the healthcheck paths and kept version 1 for the same reason. Existing consumers read the catalog exactly as before.

_{P2 Badge} Point catalog users to config add

This catalog text tells users to run ployz config create, but the command tree introduced by this commit exposes ployz config add and has no create subcommand. Anyone following schema or explain output reaches an unknown command, so the description should use the actual CLI spelling.

Useful? React with 👍 / 👎.

Fixed in 6c332a4a1. The catalog now says ployz config add.

_{P2 Badge} Match the Config mount schema to server validation

The published schema accepts any string beginning with /, including /, /etc/app/, /etc//app, and /etc/./app, while ConfigAttachment::is_canonical_dir rejects all of these. Schema-driven forms and SDK clients can therefore approve values that the same Config Store later rejects with invalid_argument; encode the canonical-directory constraints in this schema.

Useful? React with 👍 / 👎.

Fixed in 6c332a4a1. The schema pattern now refuses /, empty segments, . and .. segments, and a trailing /. A catalog test checks the pattern against ConfigAttachment::is_canonical_dir over the same sample set.

_{P2 Badge} Canonicalize Volume targets before collision checks

Fresh evidence after the canonical-Config fix: volume::attach still accepts any absolute ContainerPath, but this comparison normalizes only trailing slashes. A Service can therefore mount a Volume at /etc//sentry or /etc/./sentry and a Config at /etc/sentry; both this check and mounted_files accept the document even though the paths resolve to the same container location, violating the Config Mount invariant that each directory holds one mount. Canonicalize both target types before comparing them, including the Volume-versus-Config-file checks.

AGENTS.md reference: AGENTS.md:L7-L7

Useful? React with 👍 / 👎.

Fixed in 9bf5255aa. Both Volume checks now compare the Volume path after resolving //, . and .., the way the runtime resolves a mount target. The test covers /etc//a, /etc/./a, /etc/x/../a and //etc/..