52 lines
919 B
Markdown
52 lines
919 B
Markdown
# Change / PR Rules — podman-mvp
|
|
|
|
All non-trivial changes must follow this workflow.
|
|
|
|
## Step 1 — Scope
|
|
Describe:
|
|
|
|
- What feature is added or improved
|
|
- Which files are touched
|
|
|
|
## Step 2 — Contract safety check
|
|
|
|
Must remain TRUE:
|
|
|
|
- Existing API responses unchanged
|
|
- No JSON keys removed or renamed
|
|
- Backward compatibility maintained
|
|
- allowed_units.txt respected
|
|
|
|
If not certain → STOP and propose first.
|
|
|
|
## Step 3 — Runtime safety
|
|
|
|
Do NOT change without agreement:
|
|
|
|
- Pod structure
|
|
- Podman socket mounts
|
|
- DBus configuration
|
|
- host PID/IPC usage
|
|
|
|
## Step 4 — Verification (required)
|
|
|
|
Provide curl validation commands.
|
|
|
|
Example:
|
|
|
|
curl -s http://127.0.0.1:8081/api/...
|
|
|
|
Explain what should change in output.
|
|
|
|
## Step 5 — Refactoring
|
|
|
|
Allowed only when:
|
|
|
|
- required for feature OR
|
|
- clearly improves maintainability
|
|
|
|
Refactor must:
|
|
- keep behaviour identical
|
|
- minimize diff size
|
|
- be proposed first.
|