agent-quality-police 0.2.3 → 0.2.5
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.claude-plugin/plugin.json +1 -1
- package/.codex-plugin/plugin.json +1 -1
- package/AGENTS.md +2 -2
- package/CLAUDE.md +11 -56
- package/framework/entrypoints/global-policy.md +24 -0
- package/framework/entrypoints/{policy.md → repo-policy.md} +2 -2
- package/lib/install.mjs +1 -1
- package/package.json +1 -1
package/AGENTS.md
CHANGED
|
@@ -44,8 +44,8 @@
|
|
|
44
44
|
- Keep tests direct, short, and behavior-based.
|
|
45
45
|
- Prefer explicit domain names over generic utilities.
|
|
46
46
|
- Keep policy text severe and actionable; do not soften language to preserve agent comfort.
|
|
47
|
-
- After any change to canonical framework sources such as
|
|
48
|
-
- After the build step, run `python3 scripts/validate_framework.py`. If scripts changed, run `python3 -m unittest tests/test_framework_tools.py`.
|
|
47
|
+
- After any change to canonical framework sources such as `framework/skills/`, `framework/rules/`, `docs/policy/`, or `framework/agents/specs/`, run `python3 scripts/build_framework.py` before claiming the repository is consistent.
|
|
48
|
+
- After the build step, run `python3 scripts/validate_framework.py`. If scripts changed, run `python3 -m unittest tests/test_framework_tools.py` and `node --test tests/node/install.test.mjs`.
|
|
49
49
|
|
|
50
50
|
## Audit Flow
|
|
51
51
|
|
package/CLAUDE.md
CHANGED
|
@@ -3,66 +3,21 @@
|
|
|
3
3
|
## Priority
|
|
4
4
|
|
|
5
5
|
- Direct system, developer, and user instructions override this file.
|
|
6
|
-
-
|
|
7
|
-
-
|
|
8
|
-
- Generated projections must not become the source of truth.
|
|
6
|
+
- Prefer current local code and current official documentation over memory.
|
|
7
|
+
- Load only the smallest relevant skill set for the task.
|
|
9
8
|
|
|
10
|
-
##
|
|
9
|
+
## Quality Rules
|
|
11
10
|
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
4. Execute with TDD when tests are viable.
|
|
16
|
-
5. Run the matching audit agents before final approval.
|
|
11
|
+
- Use behavior-first tests when tests are viable.
|
|
12
|
+
- Avoid type bypasses, comment bypasses, config weakening, and fake greens.
|
|
13
|
+
- Prefer named types and explicit models over inline structural shortcuts.
|
|
17
14
|
|
|
18
|
-
##
|
|
15
|
+
## Review Flow
|
|
19
16
|
|
|
20
|
-
-
|
|
21
|
-
- Use
|
|
22
|
-
- Use
|
|
23
|
-
- Use
|
|
24
|
-
- Use [anti-bypass-audit](.claude/skills/anti-bypass-audit/SKILL.md) when reviewing diffs, suspicious helpers, or weakened configs.
|
|
25
|
-
- Use [refactoring-with-safety](.claude/skills/refactoring-with-safety/SKILL.md) for refactors that are not pure bug fixes.
|
|
26
|
-
- Use [governance-installation](.claude/skills/governance-installation/SKILL.md) when installing or updating this framework in another repository.
|
|
27
|
-
|
|
28
|
-
## Non-Negotiables
|
|
29
|
-
|
|
30
|
-
- TDD is mandatory when tests are technically viable.
|
|
31
|
-
- A passing test suite without behavior proof is not a green build.
|
|
32
|
-
- `any`, type assertions, non-null assertions, ts-comment bypasses, and lint/config weakening are automatic failures.
|
|
33
|
-
- `Map` in public or domain-facing contracts is suspicious by default and must be treated as a modeling bypass unless a stronger repository rule explicitly allows it.
|
|
34
|
-
- Helpers, factories, mocks, branches, or narrowing added only to silence the type system or to make tests easier are automatic failures.
|
|
35
|
-
- Zod is allowed only at external input boundaries.
|
|
36
|
-
- Joi is allowed only for environment validation when it is genuinely needed.
|
|
37
|
-
- Strong named types are required.
|
|
38
|
-
- Inline structural types are prohibited.
|
|
39
|
-
- Reviewers must reject suspicious diffs instead of “accepting with caveats.”
|
|
40
|
-
|
|
41
|
-
## Execution Contract
|
|
42
|
-
|
|
43
|
-
- Fix the root problem, not the symptom.
|
|
44
|
-
- Keep tests direct, short, and behavior-based.
|
|
45
|
-
- Prefer explicit domain names over generic utilities.
|
|
46
|
-
- Keep policy text severe and actionable; do not soften language to preserve agent comfort.
|
|
47
|
-
- After any change to canonical framework sources such as `.claude/skills/`, `.claude/rules/`, `docs/policy/`, or `framework/agents/specs/`, run `python3 scripts/build_framework.py` before claiming the repository is consistent.
|
|
48
|
-
- After the build step, run `python3 scripts/validate_framework.py`. If scripts changed, run `python3 -m unittest tests/test_framework_tools.py`.
|
|
49
|
-
|
|
50
|
-
## Audit Flow
|
|
51
|
-
|
|
52
|
-
- `implementer`: execution agent, allowed to write, never allowed to weaken rules.
|
|
53
|
-
- `tdd-warden`: verifies there was a real RED phase and that tests prove behavior.
|
|
54
|
-
- `bypass-auditor`: hunts bypasses, fake narrowing, config weakening, helper noise, and non-probative mocks.
|
|
55
|
-
- `pr-gatekeeper`: final verdict, does not rewrite code.
|
|
56
|
-
|
|
57
|
-
## Output Expectations
|
|
58
|
-
|
|
59
|
-
- Implementation output should state what behavior is covered, what tests were run, and what remains blocked.
|
|
60
|
-
- Audit output should list concrete findings with file evidence and required correction.
|
|
61
|
-
- Gate output should end with `APPROVED` or `REJECTED`.
|
|
62
|
-
|
|
63
|
-
## Repository Layout
|
|
64
|
-
|
|
65
|
-
- [system-layout](docs/policy/system-layout.md)
|
|
17
|
+
- Before final approval, run the relevant auditors for the actual risk surface.
|
|
18
|
+
- Use `bypass-auditor` for typing, config, mocks, helpers, or suspicious diffs.
|
|
19
|
+
- Use `tdd-warden` when behavior or tests changed or should have changed.
|
|
20
|
+
- Use `pr-gatekeeper` only for final approve-or-reject review.
|
|
66
21
|
|
|
67
22
|
## Tool-Specific Notes
|
|
68
23
|
|
|
@@ -0,0 +1,24 @@
|
|
|
1
|
+
## Priority
|
|
2
|
+
|
|
3
|
+
- Direct system, developer, and user instructions override this file.
|
|
4
|
+
- Prefer current local code and current official documentation over memory.
|
|
5
|
+
- Load only the smallest relevant skill set for the task.
|
|
6
|
+
|
|
7
|
+
## Quality Rules
|
|
8
|
+
|
|
9
|
+
- Use behavior-first tests when tests are viable.
|
|
10
|
+
- Avoid type bypasses, comment bypasses, config weakening, and fake greens.
|
|
11
|
+
- Prefer named types and explicit models over inline structural shortcuts.
|
|
12
|
+
|
|
13
|
+
## Review Flow
|
|
14
|
+
|
|
15
|
+
- Before final approval, run the relevant auditors for the actual risk surface.
|
|
16
|
+
- Use `bypass-auditor` for typing, config, mocks, helpers, or suspicious diffs.
|
|
17
|
+
- Use `tdd-warden` when behavior or tests changed or should have changed.
|
|
18
|
+
- Use `pr-gatekeeper` only for final approve-or-reject review.
|
|
19
|
+
|
|
20
|
+
## Tool-Specific Notes
|
|
21
|
+
|
|
22
|
+
- Claude Code should enter through `{{claude_entrypoint_label}}` and `{{claude_rules_root}}`.
|
|
23
|
+
- Codex should enter through this file and use `{{codex_skills_root}}` plus `{{codex_agents_root}}`.
|
|
24
|
+
- OpenCode should enter through this file and load extra instructions from `{{opencode_config_path}}`.
|
|
@@ -42,8 +42,8 @@
|
|
|
42
42
|
- Keep tests direct, short, and behavior-based.
|
|
43
43
|
- Prefer explicit domain names over generic utilities.
|
|
44
44
|
- Keep policy text severe and actionable; do not soften language to preserve agent comfort.
|
|
45
|
-
- After any change to canonical framework sources such as
|
|
46
|
-
- After the build step, run `python3 scripts/validate_framework.py`. If scripts changed, run `python3 -m unittest tests/test_framework_tools.py`.
|
|
45
|
+
- After any change to canonical framework sources such as `framework/skills/`, `framework/rules/`, `docs/policy/`, or `framework/agents/specs/`, run `python3 scripts/build_framework.py` before claiming the repository is consistent.
|
|
46
|
+
- After the build step, run `python3 scripts/validate_framework.py`. If scripts changed, run `python3 -m unittest tests/test_framework_tools.py` and `node --test tests/node/install.test.mjs`.
|
|
47
47
|
|
|
48
48
|
## Audit Flow
|
|
49
49
|
|
package/lib/install.mjs
CHANGED
|
@@ -35,7 +35,7 @@ export function supportedTargets() {
|
|
|
35
35
|
}
|
|
36
36
|
|
|
37
37
|
async function loadEntrypointPolicy(packageRoot) {
|
|
38
|
-
return (await readFile(packagePath(packageRoot, "framework", "entrypoints", "policy.md"), "utf8")).trimEnd();
|
|
38
|
+
return (await readFile(packagePath(packageRoot, "framework", "entrypoints", "global-policy.md"), "utf8")).trimEnd();
|
|
39
39
|
}
|
|
40
40
|
|
|
41
41
|
function renderTemplate(content, replacements) {
|