No AI Slop: evidence-led editing, packaging and evaluation
Read the No AI Slop package builder: seven files, prompt limits and path separators
Walk through validate_source and validate_build, including seven isolated cases and the distinction between validating a directory and inspecting ZIP contents.
What you will learn
- Source validation checks presence and some bounds
- Building and validating cover different surfaces
- A native Windows case exposes a portability limit
Before you start
- A draft whose facts can be checked
- Basic understanding of assistant instructions and plugin scope
Inspect pattern evidence, preserve meaning and distinguish package checks from unmeasured editing outcomes.
Key takeaways
- A successful source check does not validate every eventual package input.
- Directory inventory and ZIP contents are separate verification targets.
- An expected-failure fixture documents a limitation rather than certifying the platform.
Source validation checks presence and some bounds
validate_source requires truthy manifest fields and interface fields. It limits starter prompts to at most three entries of at most 128 characters, then checks that the skill, checklist and image paths exist. Our fixtures confirm acceptance at the prompt boundary and rejection for an empty version, four prompts, an overlong prompt and a missing image.
These checks are not a complete schema or content validator. A file existing at the image path is not proof that its bytes are a valid image; the function also does not require LICENSE at this stage. Our synthetic source case without LICENSE passes validation, although the later builder attempts to copy that file. This distinguishes an early check from the full build’s needs.
Building and validating cover different surfaces
build_plugin recreates a distribution subdirectory, copies the manifest, rules, checklist, artwork and three policy/license files, then writes a versioned archive. validate_build compares a seven-file directory inventory and checks that the packaged rules and checklist equal their canonical bytes. Its final ZIP test checks that the archive is a valid ZIP file.
That final check does not itself compare every ZIP member to the expected inventory. Directory validation and archive-content verification are different assertions. The current builder writes the archive from its generated directory, but a stronger independent release check would inspect the archive’s member names and bytes rather than infer them from another location.
A native Windows case exposes a portability limit
The expected inventory contains forward-slash paths, while actual entries are produced with str(path.relative_to(plugin_root)). On Windows those strings contain backslashes. Our seventh isolated case confirms rejection of a correctly populated synthetic directory at this comparison. The test passes because it documents that expected rejection; it does not mean Windows packaging passed.
The seven cases execute the pinned upstream validate_source and validate_build functions after redirecting their paths into a disposable fixture. They never invoke build_plugin or main, never install the skill and never run a model. The proposed repair is to normalize archive-style paths before comparison, then test Windows and POSIX; no upstream patch was made.
Decision guide
| Criterion | Option A | Option B |
|---|---|---|
| Best when | You need predictable behavior and easy auditing | You need adaptive optimization and have reliable telemetry |
| Main risk | May leave performance on the table | Can become difficult to explain or debug |
Implementation steps
- 1
Read required fields and boundary conditions first.
- 2
Trace which files the builder actually copies.
- 3
Separate directory, byte-equality and archive checks.
- 4
Compare native path behavior across platforms.
Copy-ready example
# Proposed portable comparison; not a patch applied upstream.
actual = {
path.relative_to(plugin_root).as_posix()
for path in plugin_root.rglob("*") if path.is_file()
}
# Independently inspect archive member names and bytes as well.Frequently asked questions
Did you run the entire package builder?
No. Only two reviewed validation functions were executed with synthetic temporary data.
What should a portability fix test?
Normalized relative paths, the exact expected file inventory and archive members on both Windows and POSIX.
Sources
- No AI Slop / scripts/build_plugin.pySource checked 2026-09-14
- No AI Slop / .github/workflows/plugin.ymlSource checked 2026-09-14
- No AI Slop / .codex-plugin/plugin.jsonSource checked 2026-09-14