Fix Dockerfile

Validate an existing Dockerfile against a fixed rule set, score it, and produce a fully remediated version. Deterministic — every rule below is a regex or a structural check, not a judgment call.

Inputs

If neither is provided → ask the user for the Dockerfile path. STOP.

Procedure

Step 1 — Read the file

If path is given, read the file content. Reject if it doesn't contain at least one FROM line (case-insensitive) — that's not a Dockerfile.

Step 2 — Run every rule

Apply each rule below in order. For each match, record an issue with { ruleId, category, severity, line, message }.

severity ∈ error (must fix) | warning (should fix) | info (nice to fix). category ∈ security | performance | bestPractices.

When a rule says "scan lines", split the file on \n, trim each line, ignore empty lines and lines starting with #.

Security rules (highest priority)

Performance / optimization rules

Best-practice / quality rules

Step 3 — Score

Start at 100. Subtract 10 per issue (any severity). Floor at 0.

Grade band:

Step 4 — Compute overall priority

• high if any security issue has severity error, OR ≥ 3 security issues total.
• medium if any security/performance/best-practice issue exists.
• low if no issues found.

Step 5 — Decide remediation strategy

Step 6 — Produce and apply the fixed Dockerfile

Walk every recorded issue and apply the corresponding fix. The fix table:

After applying all fixes, run Step 2 again as a self-check on the new content. If any rule still triggers, fix it before writing. Never write a Dockerfile that still violates a security error rule.

Step 7 — Apply the change

• If path was provided and the file scored below A (any issues found): write the remediated content to that file immediately, using whatever file-editing capability the environment exposes. Do NOT ask the user to copy-paste. Do NOT defer this to a “Next steps” list.
• If path was provided and the file already scored A with 0 issues: do nothing — the file is fine as-is.
• If only inline dockerfile content was provided (no path): you cannot write to disk — say so and include the fixed content inline.
• If the user explicitly asks to see the fixed content (“show me the file”, “print the Dockerfile”, etc.), include it under an extra Fixed Dockerfile section. Otherwise omit it — the file on disk is the artifact, not the chat output.

Output format

Use these exact sections in order:

**Dockerfile validation** — `<path or "(inline)">`

### Score
- **Grade:** <A|B|C|D|F> (<score>/100)
- **Priority:** <high|medium|low>
- **Strategy:** <rewrite|refactor|tweak>

### Issues (<N>)

#### Security (<count>)
- *<severity>* `<ruleId>` (line <line>) — <message>
- ...

#### Performance (<count>)
- *<severity>* `<ruleId>` (line <line>) — <message>
- ...

#### Best practices (<count>)
- *<severity>* `<ruleId>` (line <line>) — <message>
- ...

> If a category has 0 issues, write `- none`.

### Result
✅ Wrote remediated Dockerfile to `<path>`. <N> issue(s) fixed.

> Replace this with `✅ Dockerfile already meets the baseline. No changes
> required.` if the input scored A with 0 issues, OR with `⚠️ Inline
> content — no path provided. Fixed content below.` when only inline
> content was supplied.

### Diff summary
- **Added:** <bullet list of new instructions>
- **Removed:** <bullet list of dropped/replaced instructions>
- **Modified:** <bullet list of in-place edits>

> Omit this section entirely if no changes were applied.

### Fixed Dockerfile *(only when no path was given, or when the user asked to see it)*

```dockerfile
<full remediated Dockerfile content>
```

### Next steps
1. Rebuild: `docker buildx build --platform=<targetPlatform> -t <name>:dev <build-context>`.
2. Re-run **fix-dockerfile** to confirm score is **A** (90+).
3. Once clean, proceed to `generate-k8s-manifests`.

If the input scores A with 0 issues, the output collapses to: the Score section, the Issues section (all “none”), and the Result block — nothing else.

Constraints

• The artifact is the file on disk, not the chat output. Always write the remediated content to path immediately after Step 6 when changes are needed.
• NEVER write a Dockerfile that still has any error-severity issue.
• NEVER print the full Dockerfile in chat unless (a) no path was given, or (b) the user explicitly asks to see it.
• NEVER keep a value next to any secret-pattern env var name. Even if the user wrote it themselves, surface the violation and remove it.
• NEVER replace :latest with another floating tag; always a specific major version.
• NEVER add a HEALTHCHECK that uses tools not present in the base image (e.g. curl on distroless). Use the distroless fallback comment.
• Preserve the user's choice of base image family (don't switch node:20-alpine → mcr.microsoft.com/... unless :latest forced a retag).
• Line numbers in the issue list must reference the original file.

Failure modes