1
0
mirror of https://github.com/bestnite/quadlet-migrator-skill.git synced 2026-04-04 01:23:28 +00:00

Tighten Quadlet support-file and mount rules

Make install scripts manage only Quadlet units, keep support files in the reviewed working tree via absolute paths, and preserve file-versus-directory bind mount shape from source inputs.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
2026-04-04 03:15:04 +11:00
parent b719a3c155
commit 2f90be67c9
5 changed files with 25 additions and 19 deletions

View File

@@ -5,7 +5,7 @@ Use this file when the user asks how to verify or troubleshoot generated Quadlet
## Basic deployment flow
1. Review the generated files in the current working directory and confirm the expected Quadlet units, env files, helper scripts, and required repo-local support files exist.
2. Run `install.sh` to copy only the reviewed unit files into the target Quadlet directory and place required runtime support files into the correct host-side paths.
2. Run `install.sh` to copy only the reviewed Quadlet unit files into the target Quadlet directory.
3. Run the appropriate reload command.
4. Start the relevant units and inspect their status.
5. If needed, run `uninstall.sh` to remove the installed reviewed artifact set before regenerating or abandoning the deployment.
@@ -58,9 +58,10 @@ systemd-analyze --user verify <unit>.service
Before calling the result runnable, verify that:
- every referenced `EnvironmentFile=` exists at the installed path
- every referenced `EnvironmentFile=` exists at the path referenced by the installed unit
- required env keys are actually present in the final env sources
- bind-mounted files and directories exist after installation
- bind-mounted files and directories exist at the absolute paths referenced by the generated Quadlet files
- bind-mounted file-versus-directory shape still matches the source input
- repo-local entrypoint or helper scripts referenced by the container exist and are executable when needed
- initialization assets such as `init.sql`, seeds, bootstrap files, or config templates are present where the deployment expects them
@@ -69,7 +70,8 @@ Runnable-output gate checklist template:
- [ ] the support-file set is complete
- [ ] env completeness check passed against the actual final env sources
- [ ] unit files are installed in the intended Quadlet directory
- [ ] support files are installed at the host-side runtime paths expected by mounts and scripts
- [ ] support files remain available at the absolute paths expected by mounts and scripts
- [ ] bind-mounted file-versus-directory shape still matches the source input
- [ ] service-management scripts operate on the same artifact set that was reviewed
- [ ] no required support file, env key, or typo-suspect mismatch remains unresolved
@@ -79,7 +81,7 @@ Do not call the result runnable until every item above is checked.
- unsupported Quadlet option for the installed Podman version
- bind-mount source directory missing
- files were generated but `install.sh` has not yet copied the unit files into the target rootless or rootful unit directory and the required runtime support files into their host-side paths
- files were generated but `install.sh` has not yet copied the unit files into the target rootless or rootful unit directory
- wrong rootless or rootful apply target directory
- unresolved env file path
- required env key missing from the final env file
@@ -99,6 +101,6 @@ When validation fails, report:
## Relationship to execution phase
Validation belongs after the files are written in the execution phase and applied to a valid Quadlet directory and the correct host-side runtime paths.
Validation belongs after the files are written in the execution phase, the Quadlet units are applied to a valid Quadlet directory, and the referenced support files remain available at the absolute host paths used by the generated units.
Before execution, the skill should already have completed planning and finalize review with the user. Do not treat validation as a substitute for design review.