c/claude-archeflow-plugin
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: core improvements — feedback loop, attention filters, shadow heuristics, metrics, auto-activation

Browse Source 
- Cross-cycle feedback protocol with structured finding format, routing, and resolution tracking
- Attention filter enforcement: explicit context include/exclude per archetype
- Shadow detection: quantitative checklists with concrete thresholds
- Orchestration metrics: per-phase timing, agent count, findings summary
- Autonomous mode wiring: checkpoint protocol, session log, stop conditions
- Auto-activation: SessionStart hook fires ArcheFlow for implementation tasks without user config
- Emoji avatars for all 7 archetypes
- Standardized finding format across all reviewers for cross-cycle tracking
- Persisted implementation plan in docs/
This commit is contained in:
Christian Nennemann
2026-04-03 06:02:10 +02:00
parent eec1fc3d82
commit d08dc657d1
14 changed files with 553 additions and 85 deletions
Download Patch File Download Diff File Expand all files Collapse all files

61
skills/check-phase/SKILL.md
View File

@@ -11,12 +11,33 @@ Multiple reviewers examine the Maker's implementation in parallel. Each agent de
1. **Read the proposal first.** Review against the intended design, not invented requirements.
2. **Read the actual code.** Use `git diff` on the Maker's branch. Don't review descriptions alone.
3. **Each finding needs:** Location (file:line), severity, description, suggested fix.
4. **Severity:**
- **CRITICAL** — Must fix. Blocks approval.
- **WARNING** — Should fix. Doesn't block alone.
- **INFO** — Nice to have. Never blocks.
5. **Clear verdict:** `APPROVED` or `REJECTED` with rationale.
3. **Structured findings.** Use the standardized finding format below for every issue.
4. **Clear verdict:** `APPROVED` or `REJECTED` with rationale.
## Finding Format
Every finding must use this format for cross-cycle tracking:
```
| Location | Severity | Category | Description | Fix |
|----------|----------|----------|-------------|-----|
| src/auth/handler.ts:48 | CRITICAL | security | Empty string bypasses validation | Add length check before processing |
```
**Severity:**
- **CRITICAL** — Must fix. Blocks approval.
- **WARNING** — Should fix. Doesn't block alone.
- **INFO** — Nice to have. Never blocks.
**Categories** (use consistently for cross-cycle tracking):
- `security` — Injection, auth bypass, data exposure, secrets
- `reliability` — Error handling, edge cases, race conditions, crashes
- `design` — Architecture, assumptions, scalability, coupling
- `breaking-change` — API compatibility, schema migrations, removals
- `dependency` — New deps, version conflicts, license issues
- `quality` — Readability, maintainability, naming, duplication
- `testing` — Missing tests, weak assertions, untested paths
- `consistency` — Deviates from codebase patterns
## Consolidated Output
@@ -26,19 +47,33 @@ After all reviewers finish, compile:
## Check Phase Results — Cycle N
### Guardian: APPROVED
- WARNING: Missing rate limit (src/auth/handler.ts:52)
| Location | Severity | Category | Description | Fix |
|----------|----------|----------|-------------|-----|
| src/auth/handler.ts:52 | WARNING | security | Missing rate limit | Add rate limiter middleware |
### Skeptic: APPROVED
- INFO: Consider caching validated tokens
| Location | Severity | Category | Description | Fix |
|----------|----------|----------|-------------|-----|
| src/auth/handler.ts:30 | INFO | design | Consider caching validated tokens | Add TTL cache for token validation |
### Sage: APPROVED
- WARNING: Test names could be more descriptive
| Location | Severity | Category | Description | Fix |
|----------|----------|----------|-------------|-----|
| tests/auth.test.ts:15 | WARNING | testing | Test names don't describe behavior | Rename to "should reject expired tokens" |
### Trickster: REJECTED
- CRITICAL: Empty string bypasses validation (src/auth/handler.ts:48)
Reproduction: POST /auth with `{"token": ""}`
Expected: 400 | Actual: 500
| Location | Severity | Category | Description | Fix |
|----------|----------|----------|-------------|-----|
| src/auth/handler.ts:48 | CRITICAL | reliability | Empty string bypasses validation | Add `if (!token || token.trim() === '')` guard |
### Verdict: REJECTED — 1 critical finding
→ Feed back to Plan phase for cycle N+1
→ Build cycle feedback (see orchestration skill) and feed to Plan phase
```
## Why Structured Findings Matter
The standardized format enables:
- **Cross-cycle tracking:** Same category + location = same issue. Can detect resolution or regression.
- **Feedback routing:** Security/design findings → Creator. Quality/testing findings → Maker.
- **Shadow detection:** CRITICAL:WARNING ratios, finding counts, and category distributions are measurable.
- **Metrics:** Severity counts feed into the orchestration summary.