fix: tech-debt: sweep cron-isms from code comments, helpers, lib, and public site copy (#548)
All checks were successful
ci/woodpecker/push/ci Pipeline was successful
ci/woodpecker/pr/ci Pipeline was successful
ci/woodpecker/pr/smoke-init Pipeline was successful

- Rename acquire_cron_lock → acquire_run_lock in lib/formula-session.sh
  and all five *-run.sh call sites
- Update all *-run.sh file headers: "Cron wrapper" → "Polling-loop wrapper"
- Rewrite docs/updating-factory.md: replace crontab check with pgrep,
  replace "Crontab empty after restart" section with polling-loop equivalent
- Update docs/EVAL-MCP-SERVER.md to reflect polling-loop reality
- Update lib/guard.sh, lib/AGENTS.md, lib/ci-setup.sh comments
- Update formulas/*.toml comments (cron → polling loop)
- Update dev/dev-poll.sh usage comment
- Update tests/smoke-init.sh to handle compose vs bare-metal scheduling
- Update .woodpecker/agent-smoke.sh comments
- Update site HTML: architecture.html, quickstart.html, index.html
- Clarify _install_cron_impl is bare-metal only (compose uses polling loop)
- Keep site/collect-engagement.sh and site/collect-metrics.sh cron refs
  (genuinely cron-driven on the website host, separate from factory loop)

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Claude 2026-04-10 08:54:11 +00:00
parent da4d9077dd
commit f0c3c773ff
24 changed files with 115 additions and 132 deletions

View file

@ -39,9 +39,11 @@ programmatically instead of parsing SKILL.md instructions.
(`mcp` package). This adds a build step, runtime dependency, and
language that no current contributor or agent maintains.
2. **Persistent process.** The factory is cron-driven — no long-running
daemons. An MCP server must stay up, be monitored, and be restarted on
failure. This contradicts the factory's event-driven architecture (AD-004).
2. **Persistent process.** The factory already runs a long-lived polling loop
(`docker/agents/entrypoint.sh`), so an MCP server is not architecturally
alien — the loop could keep an MCP client alive across iterations. However,
adding a second long-running process increases the monitoring surface and
restart complexity.
3. **Thin wrapper over existing APIs.** Every proposed MCP tool maps directly
to a forge API call or a skill script invocation. The MCP server would be