theslopmachine 1.0.10 → 1.0.11
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.
|
@@ -44,6 +44,8 @@ When sending issues to a developer lane:
|
|
|
44
44
|
## Regenerated Report Validation
|
|
45
45
|
|
|
46
46
|
When a failed report is regenerated in the same evaluator session:
|
|
47
|
+
- regeneration happens only after the failed report has been archived unchanged, all issues from that failed report have been sent to the bugfix lane, fixes have been made, and the owner has verified those fixes
|
|
48
|
+
- the regeneration instruction must be the stored regeneration prompt verbatim, with no added preface, suffix, explanation, or wording changes
|
|
47
49
|
- reject reports under 150 lines
|
|
48
50
|
- reject reports materially smaller or shallower than the archived report
|
|
49
51
|
- reject reports that expose regeneration language such as `remaining`, `still`, `now`, or similar history-aware wording
|
|
@@ -67,7 +69,7 @@ When a failed report is regenerated in the same evaluator session:
|
|
|
67
69
|
- Read the full fix-check report.
|
|
68
70
|
- If every scoped issue is fixed, save/keep the fix-check report.
|
|
69
71
|
- If anything is not fixed or partially fixed, send only the unresolved behavior back to the developer lane in broad human language, then rerun the fix-check in the same evaluator session.
|
|
70
|
-
- The regenerated fix-check must still address the full kept audit issue set.
|
|
72
|
+
- The regenerated fix-check must still address the full kept audit issue set, not only the unresolved items that were most recently sent back.
|
|
71
73
|
- Reject fix-check reports that narrow the scope, skip low-priority kept issues, perform a broad new audit instead of scoped checking, or use history-exposing language.
|
|
72
74
|
- Do not edit evaluator report text.
|
|
73
75
|
|
|
@@ -62,7 +62,8 @@ Run this procedure twice: once for Audit Cycle 1 and once for Audit Cycle 2.
|
|
|
62
62
|
- Emphasize prompt-fit/compliance and security issues internally when prioritizing remediation.
|
|
63
63
|
- Convert the issue list into broad human language.
|
|
64
64
|
- Send the full issue set to the existing bugfix lane without file/line details, report names, or evaluator language.
|
|
65
|
-
-
|
|
65
|
+
- Do not run a fix-check for a Fail report. First fix every issue from the failed report and verify the fixes owner-side.
|
|
66
|
+
- After the bugfix lane fixes every issue from the failed report and the owner verifies, return to the same evaluator session and send this exact regeneration instruction verbatim, with no additions, removals, preface, suffix, or wording changes:
|
|
66
67
|
|
|
67
68
|
```text
|
|
68
69
|
Regenerate the audit on a new file. Check, I fixed every issues you identified. but don't make it obvious that it is a regeneration, you shouldn't mention that the previous issues are fixed on the current audit, just put the new updated verdict and only mention remaining or newly found issues.
|
|
@@ -74,7 +75,7 @@ Refrain from using words like "Remaining, still, now", and the likes that may ex
|
|
|
74
75
|
- If the regenerated report is less than 150 lines or materially less complete than the archived report in content size/depth, reject it and resend the full prepared evaluation prompt.
|
|
75
76
|
- Reject the regenerated report if it is continuation-shaped, fix-only, materially omits required sections/tables/verdict panels/evidence style, or appears stale against current repo state.
|
|
76
77
|
- If the regenerated report is reasonably similar in depth and structure, proceed with its verdict.
|
|
77
|
-
- If the regenerated report is still Fail,
|
|
78
|
+
- If the regenerated report is still Fail, archive it unchanged, extract every issue again, fix every issue again through the bugfix lane, owner-verify again, then return to the same evaluator session and send the same exact regeneration instruction verbatim again.
|
|
78
79
|
- Continue until the cycle reaches Partial Pass or Pass.
|
|
79
80
|
|
|
80
81
|
### 3. If The Report Is Partial Pass
|
|
@@ -92,6 +93,7 @@ Refrain from using words like "Remaining, still, now", and the likes that may ex
|
|
|
92
93
|
- Cycle 1: `./.tmp/audit_report-1-fix_check.md`
|
|
93
94
|
- Cycle 2: `./.tmp/audit_report-2-fix_check.md`
|
|
94
95
|
- If the fix-check says any item is only partially fixed or not fixed, send those items back to the bugfix lane, then regenerate the fix-check report in the same evaluator session.
|
|
96
|
+
- When rerunning a fix-check after unresolved items are fixed, the evaluator must still check the whole kept audit issue list, not only the items that were sent back most recently.
|
|
95
97
|
- Reject fix-check reports that do not address the full kept audit issue set.
|
|
96
98
|
- Reject fix-check reports that use history-exposing language such as `remaining`, `still`, `now`, `resolved`, `left`, or compare the current repository against the previous report instead of checking the scoped issues against current evidence.
|
|
97
99
|
- Repeat until the fix-check confirms all scoped issues are fixed.
|