design: audit project files for drift against canonical CI/CD Components
## Context bart audits GitLab project *settings* (protected branches, labels, container registry rules) for drift against policy. There's a parallel gap that nothing today covers: drift in project *files* against canonical CI/CD pipeline pieces — `.gitlab-ci.yml`, `Dockerfile`, build-tool config, etc. The patterns library in [mson/docs#29](https://gitlab.com/mson/docs/-/issues/29) codifies the building blocks projects should compose from. CI Components (mr-reporter#13) cover the *generation* side: new projects `include:` versioned components and the pipeline assembles. What's missing is the audit side: "is this project's CI still aligned with the current canonical pieces, or has it drifted?" The conceptual fit is strong with bart — same "policy / drift / audit" mental model, just a different data source (repo file contents vs GitLab API settings). bart's CLI, audit-report format, and exception/exemption mechanics already exist. ## What to figure out (needs refinement) - **Does bart's mission accommodate file-content audit, or is that overreach?** "Manage GitLab project settings as policy" reads tight. Widening to "manage GitLab project state as policy" makes file-audit natural; staying narrow argues for a sibling tool that shares only the report format. - **If extension:** new policy domain (e.g., `bart audit files`) reading project files via the Repository API; rules express "this file should match the rendered output of component X@vY". - **If sibling tool:** separate binary with the same CLI/report shape, optionally importable as a library if bart wants to delegate. ## Scope sketch (either way) - Pull files from a GitLab project (via API or a local clone). - Re-render the canonical form from CI Components / templates. - Diff per-file; report findings in bart's existing audit format. - Auto-fix (open an MR with the rendered files) is a stretch, not MVP. ## Related - mson/docs#29 — pattern library that names the canonical pieces. - mr-reporter#13 — CI Components extraction; depends on those components existing as the canonical source to audit against. *Generated with Claude Code*
issue