generated-runtime-repairs

Topics in the source

• Generated runtime repairs
• When to Use
• 1. Freeze scope and current inputs
• 2. Reproduce and repair at the source
• 3. Prove the staged artifact
• 4. Land source without mixing other writers' work
• 5. Deploy only approved targets and read them back
• 6. Close the handoff without chatter

Repair repository-owned wrappers and scheduled routines without confusing source correctness with deployment. Load the repository contract and the relevant runtime skill for its supported commands. A repo owns a template/routine that is materialized into agent profiles, cron jobs, or wrapper scripts. A generated file misbehaves and the fix must go to the template/generator, not the generated copy. A reviewed candidate patch must be landed into a shared checkout and/or deployed to the live runtime. Verify relayed permission changes against the operator's primary record and current contract. Classify source edits, Git publication, and live runtime writes separately; standing commit/push authorization does not authorize profile/config/cron/session writes. Fetch and fast-forward before source work. Inspect current status/diff and patch applicability immediately before landing; peers and scheduled publishers can invalidate an earlier clean-tree report. When landing a candidate built against an earlier base, prove each target file byte-identical to that base (git show : piped to cmp against the working copy) — the shared HEAD moving on does not by itself invalidate the candidate, but a c

This is an excerpt. Refer to the complete source and its current requirements.