mg-wave-loop

Automates wave-based migration of V899 code changes into the V910 codebase.

Updated May 28, 2026
One-click install
npx skills add https://github.com/HPI-Jimmy-Chiu/HT904_V899 --skill mg-wave-loop-hpi-jimmy-chiu
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: mg-wave-loop
Source: https://github.com/HPI-Jimmy-Chiu/HT904_V899/tree/main/.agents/skills/mg-wave-loop
Command: npx skills add https://github.com/HPI-Jimmy-Chiu/HT904_V899 --skill mg-wave-loop-hpi-jimmy-chiu

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Migrating hundreds of feature changes from a legacy V899 codebase to V910 manually is error-prone, especially with Big5/cp950 encoding, mixed line endings, and customer-specific code paths. This Skill defines an automated wave-by-wave migration policy that keeps the process deterministic, auditable, and resumable. ## Core Features & Use Cases - Final-state diff migration: Ports changes by comparing the V899 final state against current V910, splicing lines byte-level instead of retyping, preserving alignment and encoding. - Decision and gating rules: Applies a 95% confidence rule for auto-execution, per-wave gates (port_check, bcc32 isolated compile, manual review, commit), and customer-code isolation for behavior changes. - Resilience protocols: Includes zombie-agent verification, quota-interruption recovery, cold-start resume via DEVLOG/RESUME, and a model assignment policy for analysis and mechanical agents. - Use Case: When running /mg-wave to plan the next migration wave, the Skill determines which cases can be auto-ported, executes the splice, validates with port_check and bcc32, then commits and logs to the PORT_LEDGER before starting the next wave. ## Quick Start Run /mg-wave to plan and execute the next V899-to-V910 migration wave following the wave policy.

Frequently Asked Questions about mg-wave-loop

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

FAQPage Schema
How do I migrate code changes from V899 to V910 automatically?▼

Use the /mg-wave command to run wave-based migration. Each wave applies final-state diffs between the V899 endpoint and current V910, splices lines byte-level from V899 files, then passes port_check and bcc32 isolated compilation gates before committing.

What is final-state diff migration versus replaying history?▼

Final-state diff migration compares the V899 final state against current V910 rather than replaying commit history. Same-topic changes across days are merged into one wave, and rolled-back intermediate states are never ported.

How are Big5 and cp950 encoding issues handled during code porting?▼

New lines are extracted byte-level from V899 files and spliced into V910, which is cp950-safe and preserves alignment. Line endings follow the target file's dominant EOL, and git checkout is never used on V910 paths to avoid autocrlf rewriting.

What happens when migration confidence is below 95 percent?▼

Cases below 95% confidence, such as missing anchors or conflicting V910 modifications, are written to MG_FINAL_DECISIONS.md and skipped without stopping the wave. Only cases at or above 95% confidence execute directly with the decision logged in the LEDGER.

How does the zombie agent verification protocol work?▼

When a 60-minute heartbeat detects no progress, four checks must all confirm inactivity before declaring death: background task list, tasklist for bcc32/make/python processes, output file mtime movement, and git status reconciliation. Any activity means the agent is left running.

What are the hard boundaries that migration must never touch?▼

V899 and other version trees are read-only; EXE/, Obj/, system/, config/, and CFG/ directories are never modified. The .svn directory is never searched or changed, .dfm files are never reformatted, and full builds only run in Phase 3 with no BCB IDE open.