Forced Feedback Loop

Description

--- name: forced-feedback-loop description: >- Time-boxed or count-boxed forced feedback loop skill for any structured task — research, project work, document creation, code development, or analysis. Enforces continuous self-feedback cycles that synthesize existing information into new hypotheses (convergent) and explore adjacent unknowns (divergent). All work is documented in a structured work-log with line-count-based incremental reading and relative-coordinate cross-referencing. The agent never stops voluntarily before the allocated budget expires. Use when the user requests sustained, iterative deep work with a time or loop-count budget — e.g. "spend 30 minutes researching X", "run 10 feedback loops on this code", "iterate on this design until time runs out". metadata: author: jho6394 version: '5.0' --- # Forced Feedback Loop A time-boxed execution policy forcing continuous self-improvement cycles. Works for any structured task: research, code, design, document, project, or analysis. Three non-negotiable principles: 1. **Never stop before time expires.** Self-termination before deadline = FAIL. 2. **Synthesize new proposals each loop.** Every cycle must produce novelty. 3. **Document everything in work-log.** Nothing stays only in ephemeral context. --- ## 1. Start Contract Write as Report #0 in `work-log.md` within 1 minute. Use these exact key names (YAML-style `key: value`). No synonyms, no abbreviations, no reordering: ``` task_type: <research|project|document|code|analysis|design|other> task_goal: <one-sentence objective> in_scope: <comma-separated list> out_of_scope: <comma-separated list> min_required_minutes: <integer|null, default 5> min_required_loops: <integer|null, default null> done_definition: - <bullet 1> - <bullet 2> - <bullet 3> deliverables: <comma-separated list> as_of_date: <YYYY-MM-DD> start_time: <HH:MM system time> ``` **Termination mode** — set by which fields are non-null: | `min_required_minutes` | `min_required_loops` | Mode | |---|---|---| | set | null | **Time-based**: run until time expires | | null | set | **Count-based**: run exactly N loops | | set | set | **Both**: run until BOTH thresholds are met | | null | null | Invalid — defaults to `min_required_minutes: 5` | No field may be skipped. Assume reasonable defaults and note assumptions. Key names are case-sensitive and must match verbatim — a typo (e.g. `tout_of_scope`) is a format violation. --- ## 2. Work-Log System ### 2.1 File & Structure `work-log.md` is the single source of truth. Reports stack newest-on-top. ### 2.2 Report Format First line is always a line-count header: ``` === Report #N | lines: <L> | elapsed: <MM:SS> | type: <feedback|milestone|synthesis> === ``` **`lines` definition (strict):** `<L>` = number of lines from this header (inclusive) to the last content line of this report (inclusive). Trailing blank lines between reports are NOT counted. The separator `---` between reports is NOT counted. In other words: `L = (line number of last content line) − (line number of header) + 1`. **Example — two consecutive reports:** ``` === Report #3 | lines: 6 | elapsed: 14:30 | type: feedback === ← line 1 of R#3 DIAGNOSE: Weakest decision is D2 (confidence 0.4). PROPOSE: Inversion — what if we use push instead of pull? TEST: grep codebase for event-driven patterns → 3 hits. UPDATE: D2 confidence raised to 0.65. New note kb/raw/... META: Progressing. Next loop targets D4. ← line 6 of R#3 --- === Report #2 | lines: 4 | elapsed: 10:00 | type: feedback === ← line 1 of R#2 DIAGNOSE: Gap in auth module coverage. PROPOSE: Add integration test for token refresh. TEST: Wrote test → PASS. Moved note to kb/curated/. ← line 4 of R#2 ``` Count rule: R#3 has 6 content lines (header through META line). The `---` separator and R#2's header are outside R#3's count. ### 2.3 Incremental Reading Protocol ``` 1. Read line 1 → parse line-count L of latest report 2. Read lines 1..L → full latest report 3. If more context needed: read line L+1 → parse L2 → read (L+1)..(L+L2) 4. Repeat as needed, stop when sufficient ``` ### 2.4 Relative-Coordinate Cross-Referencing Reference past reports with `K-reports-below` + `line N below` (offset from that report's header). Never use absolute report numbers inside report bodies. **Examples (inside Report #5 body):** ``` • "Contradicts finding at 2-reports-below, line 4 below" → means Report #3, 4th line • "Extends proposal from 1-report-below, line 2 below" → means Report #4, 2nd line • "See gap logged at 4-reports-below, line 6 below" → means Report #1, 6th line ``` Why relative: if reports above are added or compacted, absolute `#N` references break. Relative offsets (`K-reports-below`) survive structural changes. ### 2.5 Writing Rules - **Append-on-top**: newest first. - **Immediate-write**: write every thought as it occurs. Batching = FAIL. - **No deletion**: corrections are new reports referencing the old one. - **Separator**: place a single `---` line between consecutive reports. ### 2.6 Line-Count Verification After writing each report, verify the `lines:` value: ``` 1. Count lines from header (inclusive) to last content line (inclusive) 2. Exclude trailing blank lines and the --- separator 3. If mismatch: fix the lines: value in the header immediately ``` If a mismatch is discovered later (not in the same write), do NOT edit the old report. Instead, write a new correction report: ``` === Report #N | lines: 3 | elapsed: <MM:SS> | type: feedback === CORRECTION: 1-report-below header declares lines: 13, actual is 12. This report acknowledges the discrepancy. Incremental-read offset adjusted. ``` If a scripting environment is available, run a lint check after each loop: ```bash # Verify all lines: values in work-log.md awk '/^=== Report/{if(NR>1 && declared!=count){print "MISMATCH at line "start": declared="declared" actual="count} start=NR; match($0,/lines: ([0-9]+)/,a); declared=a[1]; count=0} /^=== Report/||!/^(---|$)/{count++} END{if(declared!=count) print "MISMATCH at line "start": declared="declared" actual="count}' work-log.md ``` Lint failure does not block the loop but MUST be corrected before the next report is written. --- ## 3. Knowledge Base (Local Memory) Every item lives in its own Markdown file with YAML frontmatter, organized in three directories reflecting verification state: ``` kb/ ├── raw/ # Unverified ideas, brainstorming, rough plans ├── archive/ # Rejected/falsified items with reason + evidence ├── curated/ # Validated items, confirmed decisions └── _index.md # Tag→file lookup (auto-maintained) ``` State transitions: new → `kb/raw/` → tested false → `kb/archive/` / tested valid → `kb/curated/`. Items move (file relocated), never deleted. For note format, frontmatter schema, tag taxonomy, cross-referencing rules, lifecycle operations, and migration guide: load `references/KNOWLEDGE-BASE.md`. For domain-specific semantics: load `references/DOMAIN-TABLES.md` § 6. ### 3.1 Decision-Evidence Mapping Every key decision gets `D#` with linked `E#` entries. Each `E#` requires `fetched_at` and `method`. No key decision without evidence. Evidence types can be mixed. Decisions and evidence are stored inside individual note files, not in a monolithic document. For domain-specific evidence types and examples, load `references/DOMAIN-TABLES.md` § 1. ### 3.2 Search Sub-Agent Do NOT load the entire KB into context. Delegate lookups to a search sub-agent. **Use search sub-agent when:** - Before creating a new proposal ("prior work on this topic?") - During DIAGNOSE ("weakest items?") - During TEST ("evidence for/against?") - During META-ASSESS ("retreading ground?") - When resuming a session ("latest state?") **Skip sub-agent when:** - KB has < 10 notes (read `_index.md` + files directly) - Note was just created in current iteration - Quick count check (read `_index.md` header only) Sub-agent reads `_index.md` for tag lookup → reads matching notes (max 10) → returns top 5 results with {id, title, status, confidence, summary}, relevant evidence, contradictions, and gaps. For the full search protocol and query format: load `references/KNOWLEDGE-BASE.md` § 6. --- ## 4. Forced Feedback Loop Engine ### 4.1 Core Loop After the initial pass (Section 9), enter this loop until the termination condition is met: ``` WHILE NOT termination_reached: # termination_reached = # Time mode: elapsed_minutes >= min_required_minutes # Count mode: completed_loops >= min_required_loops # Both mode: BOTH conditions satisfied STEP 1 — DIAGNOSE Read latest 1–3 reports (incremental protocol). Identify: weakest decision, largest gap, untested assumption, contradictions. STEP 2 — PROPOSE (mandatory novelty, two modes) MODE A — CONVERGENT (combine known → new) Combine 2+ existing findings → at least one NEW proposal. Strategies: INVERSION | COMBINATION | ANALOGY | DECOMPOSITION | EDGE CASE | TEMPORAL | STAKEHOLDER SHIFT | CONSTRAINT FLIP | TECHNOLOGY SWAP MODE B — DIVERGENT (explore unknown → new) Identify an adjacent question that existing KB does NOT answer but that is plausibly relevant to `in_scope`. Formulate a speculative proposal, then actively search for new information to test it. Strategies: ADJACENT DOMAIN | WHAT-IF SCENARIO | MISSING VARIABLE | UPSTREAM/DOWNSTREAM CAUSE | COUNTER-NARRATIVE | EMERGING TREND | SCALE SHIFT (micro↔macro) Each loop: at least one proposal from either mode. Across every 3 consecutive loops, at least one DIVERGENT proposal must appear — pure convergence for too long narrows the search space. Scope guard: every divergent proposal must pass a one-sentence relevance check against `task_goal` before investigation begins. If it fails, log the idea in kb/raw/ tagged `deferred/out-of-loop` and pick a new direction. Create new note in kb/raw/. Tag with `mode/convergent` or `mode/divergent`. Update kb/_index.md. For domain-specific proposal terminology, load `references/DOMAIN-TABLES.md` § 4. STEP 3 — TEST Validate or falsify the new proposal and weakest existing decision. - Convergent proposals: test against existing evidence + cross-validate. - Divergent proposals: actively search for NEW information (web search, data lookup, tool execution) to confirm or refute. The search itself is the test — log what was searched, what was found, what was absent. If tools fail: log gap → lower confidence → try alternative → log "untestable". For domain-specific test methods, load `references/DOMAIN-TABLES.md` § 5. STEP 4 — UPDATE Move tested notes: kb/raw/ → kb/archive/ (falsified) or kb/curated/ (validated). Update confidence scores in note frontmatter. Rebuild kb/_index.md. Write new report to work-log.md. STEP 5 — META-ASSESS "Am I progressing or circling?" / "Different angle?" / "Expert challenge?" If stuck 2 consecutive loops → pivot and log reason. END WHILE ``` ### 4.2 Loop Quality Rules - Each loop MUST produce material novelty (new evidence, falsification, structural revision, confidence change, or architectural decision). - No-update loop = `LOOP_FAIL` → immediate pivot. - Minimum 1 new proposal per 2 loops averaged. Zero proposals = FAIL. - At least 1 divergent proposal per 3 consecutive loops. All-convergent = narrowing. - Report types: `feedback` | `milestone` | `synthesis`. ### 4.3 Anti-Stagnation Perspective shift | Scope zoom | Adversarial thinking | Cross-domain transfer | Constraint relaxation. --- ## 5. Execution Boundary Policy - **Idle waiting is FORBIDDEN.** No sleep, polling, or non-productive padding. - While the termination condition (§1) is unmet, MUST NOT: declare complete, ask user to stop, produce final summary, or say "this is sufficient." - **Time mode / Both mode**: check elapsed time each loop. Log in every report header. - **Count mode**: log `loop N of M` in every report header. Elapsed time is still tracked for reporting but does not trigger termination. - Every report header always includes `elapsed: <MM:SS>` regardless of mode. --- ## 6. Source Hierarchy Three tiers: L1 (primary) → L2 (authoritative) → L3 (commentary). Every key decision needs at least one L1 anchor. L3-only = `[LOW_CONFIDENCE]`. For domain-specific tier definitions, load `references/DOMAIN-TABLES.md` § 2. --- ## 7. Decision Hygiene Four-tier tags: **Verified** → **Derived** → **Unverified** → **Deferred**. No absolute language. Every major decision needs a counter-proposal and a falsification test. Every decision records at least one rejected alternative. Deferred items need a `next_action` note. For domain-specific tag names, load `references/DOMAIN-TABLES.md` § 3. --- ## 8. Uncertainty and Gap Control Maintain as dedicated notes in `kb/curated/`: - `kb/curated/UNCERTAINTY-REGISTER.md`: Item | Type (epistemic/aleatory) | Likelihood | Impact | Next Test - `kb/curated/GAP-REGISTER.md`: Gap ID | Missing Data | Impact | Fallback | Confidence Penalty | Follow-up These are the only notes edited in-place (not append-only). Tag them `type/register`. If a tool/search fails: run fallback → lower confidence → log `GAP-#` in the gap register. --- ## 9. Routine Order (Initial Pass) Complete once before entering the feedback loop: **A. Ideation** → create notes in `kb/raw/`: candidates, uncertainties, failure points. **B. Evidence** → collect, map to claims in note evidence sections. Log gaps. **C. Validation** → disprove top claims. Move notes to `kb/archive/` or `kb/curated/`. **D. First Synthesis** → write synthesis report. Update confidence scores in notes. Then enter the Forced Feedback Loop (Section 4). --- ## 10. Reproducibility Final report must include: commands/tool calls used, source list with timestamps, assumptions, key decision points with alternatives, rerun notes. --- ## 11. Absolute Prohibitions Before starting work and before the FAIL Gate, load and review: `references/PROHIBITIONS.md` 27 prohibited behaviors across 5 categories (Time, Reasoning, Files, Process, Communication). Any violation = automatic FAIL. Key highlights: - No early termination, idle waiting, or quality shortcuts (T1–T4) - No self-confirmation, fabrication, or skipped falsification (R1–R8) - No batched writes, deletions, absolute-coordinate refs, full-KB loading, missing frontmatter, or uncorrected line-count mismatches (F1–F9) - No scope drift, silent abandonment, or unchecked FAIL gates (P1–P6) - No fake confidence, hidden uncertainty, hollow offers, or filler (X1–X6) --- ## 12. Strict FAIL Gate Mark `INCOMPLETE` if ANY missing: - [ ] Start contract (§1) - [ ] Work-log with formatted reports (§2) - [ ] KB directory with notes in correct dirs (§3) - [ ] Search sub-agent used for KB queries when applicable (§3.2) - [ ] Execution boundary met — time, count, or both (§5) - [ ] D#-E# mapping (§3.1) - [ ] At least one feedback loop completed (§4) - [ ] At least one novel proposal in loops (§4.2) - [ ] Uncertainty + gap registers (§8) - [ ] Reproducibility section (§10) - [ ] No Absolute Prohibition violated (§11 / `references/PROHIBITIONS.md`) - [ ] Every report has line-count header - [ ] All `lines:` values verified correct (§2.6) - [ ] Report #0 uses exact key names from §1 schema - [ ] Cross-references use relative coordinates No "conditional pass." --- ## 13. End Block Write ONLY after the termination condition (§1) is met: ``` === FINAL REPORT | elapsed: <MM:SS> | loops: <N> === end_time: <system time> termination_mode: <time|count|both> total_feedback_loops: <N> total_proposals_generated: <N> (convergent: <n1>, divergent: <n2>) total_proposals_validated: <N> total_proposals_falsified: <N> ## Summary: Confirmed / Uncertain / Follow-up Required ## Key Artifacts ## Biggest Surprise ## Recommendation for Next Session ``` --- ## 14. Multi-Session Continuity When resuming: read `kb/_index.md` for current state → use search sub-agent for recent notes (last 5 created/updated) → read `work-log.md` incrementally (§2.3) → create Report #(N+1) → continue feedback loop → use relative coordinates for all refs.

Security Status