Expose Crane run cadence as an installer choice and tuning guide

Start with install.md and trace how the cadence prompt is handled, then inspect workflows/crane.md and the gh aw compile step. Compare the cadence guidance needed in README.md and create-migration.md, including workflow cadence versus migration schedule frontmatter. Done means the selected cadence is applied before compilation, the trade-offs are documented, and the relevant documentation or prompt tests pass.

Background

The githubnext/apm migration needed faster iteration than the default Crane cadence. APM locally changed the Crane workflow schedule from every 6h to every 20m so Crane could converge in hours rather than days while maintainers were actively watching.

That should not necessarily become the upstream default. It should become an explicit installation and tuning choice.

Problem

The upstream Crane workflow defaults to a fixed schedule. The README explains that users can tune cadence, and install.md asks about migration frequency, but the installed workflow still needs a clear path for applying and documenting the chosen cadence.

Different migrations need different cadences:

• Active, high-attention migration: every 20m or every 1h.
• Normal migration in a busy repository: every 6h.
• Low-risk background migration: daily or weekly.
• Multiple active migrations: cadence interacts with the scheduler because each run selects only one migration.

If the cadence is too slow, Crane appears idle and migrations take too long. If it is too fast, maintainers get too many commits and CI runs.

Proposed implementation

Update Crane installation and documentation so cadence is a first-class choice.

Implementation options:

1. In install.md, keep the frequency prompt but make the follow-through explicit:

   • The agent should edit workflows/crane.md to set on.schedule to the selected cadence.
   • Then it should run gh aw compile crane.

2. In README.md, add a cadence tuning section with examples:

on:
  schedule: every 20m

on:
  schedule: every 1h

on:
  schedule: every 6h

3. Explain trade-offs:

   • Faster cadence gets feedback quickly but increases CI usage and review pressure.
   • Slower cadence is calmer but may make migrations look stalled.
   • For multiple migrations, faster workflow cadence may still run only one selected migration per trigger.

4. Consider adding guidance to create-migration.md for per-migration schedule: frontmatter versus workflow-level cadence. Users should understand both knobs:

   • Workflow cadence: how often Crane wakes up.
   • Migration schedule: whether a specific migration is due when Crane wakes up.

Suggested test coverage

• Documentation test or prompt test that asserts install.md says to update workflows/crane.md and compile after selecting cadence.
• If installer automation exists, test that the selected cadence changes the workflow source before compilation.

Acceptance criteria

• A new Crane installer run asks for cadence and applies it to the workflow source.
• Documentation explains recommended cadence ranges and trade-offs.
• Documentation distinguishes workflow wake-up cadence from per-migration schedule frontmatter.
• Users can reproduce the APM-style fast loop intentionally without hand-editing undocumented workflow internals.

Provenance

This came from githubnext/apm, where changing Crane to every 20m helped the Python-to-Go migration converge much faster while humans were actively reviewing.