loop-engineering

Manages verification convergence loops with fingerprint-based failure attribution and retry accounting.

Updated Jun 9, 2026
One-click install
npx skills add https://github.com/lechao365/AndroidSystemEnhance --skill loop-engineering-lechao365
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: loop-engineering
Source: https://github.com/lechao365/AndroidSystemEnhance/tree/main/harness/skills/loop-engineering
Command: npx skills add https://github.com/lechao365/AndroidSystemEnhance --skill loop-engineering-lechao365

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires pyyaml.

What problem does it solve? When an AI agent runs a verify-fix-retry loop for embedded system validation, loop state (attempt counts, failure fingerprints, exit reasons) lives in fragile conversation context and gets lost. This Skill moves that bookkeeping into a persistent session.json state machine so scripts handle mechanical accounting while the AI focuses on failure analysis and code fixes. ## Core Features & Use Cases - Dual-layer counting: patience counter (increments only when the same failure fingerprint freezes, cap 3) plus total_attempts cost guardrail (cap 10), preventing infinite retry loops. - Failure fingerprinting: hashes (failed stage, verify exit code, normalized first error line) with timestamp/path/hex-address normalization to distinguish a frozen problem from an evolving one. - Five-way attribution and exit protocol: classifies each round as pass, task_fail, env_fail, framework_error, or param_error, and terminates with pass, task_unsolvable, cost_cap_exceeded, env_fail, or framework_error, generating a diagnosis report skeleton. - Use Case: After a Raspberry Pi 5 build fails acceptance testing, start a session, run the workspace-verify workflow, record each receipt with done, and let the state machine decide when to stop retrying and emit a diagnosis for handoff. ## Quick Start Start a verification convergence session for target dev with a verify-cases label, then follow the run guidance and record each receipt with done until the session terminates.

Frequently Asked Questions about loop-engineering

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I manage an AI verify-fix-retry loop without losing state?

Use the ws_session.py state machine: start creates a persistent session.json, run prints the verification steps, and done records each receipt. The script tracks attempts and fingerprints so loop state survives across AI conversation turns.

How does failure fingerprinting decide when to stop retrying?

Each failure is fingerprinted from the failed stage, verify exit code, and normalized first error line (timestamps, home paths, and hex addresses stripped). Patience increments only when the same fingerprint repeats; at 3 frozen failures the session exits as task_unsolvable.

What is the difference between mode A and mode B sessions?

Mode A is launched by cross-device-apply with a --batch-file from a CDP batch. Mode B is triggered locally with --target and --case for manual regression, revert verification, or smoke testing. Both share the same state machine.

Can the loop retry after a framework_error attribution?

No. framework_error indicates a harness script exception such as a traceback, and the session terminates immediately. Retrying framework bugs is forbidden because it would disguise tooling defects as unfixable tasks.

What happens if the session.json file is lost or corrupted?

The skill degrades to calling workspace-verify directly as the baseline behavior. Corrupted session files are skipped during reuse and pruning, and loading an invalid session returns exit code 3.

Why was my receipt rejected when calling done?

Receipts with result values other than pass or fail (such as skip or revert) carry no verification conclusion and are rejected without consuming an attempt. Pass receipts also require acceptance JSON with overall pass and no fail items.