[pull] main from Dicklesworthstone:main by pull[bot] · Pull Request #154 · joyshmitz/agentic_coding_flywheel_setup

pull · 2026-03-14T02:54:13Z

See Commits and Changes for more details.

Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

A previously-fetched checksums.yaml that was missing entries for some required tools (e.g. an upstream PR landed an installer rename without updating every required-tool block) could survive the "^installers:" presence check the prior commit introduced. The cached file would then be promoted into use even though refresh_checksums saw a partial document, and downstream checksum verification would fail confusingly later when the missing tool was looked up. Add a stricter validator that the freshly-fetched file actually declares each required tool with both a url: and a sha256: field before it is allowed to replace the cached copy. scripts/lib/update.sh (+106/-): - update_required_checksum_tools() emits the canonical list of tools that every checksums.yaml must declare: atuin bun bv caam cass claude cm dcg gemini_patch mcp_agent_mail ntm ohmyzsh ru rust slb ubs uv zoxide Encoded as a function (not a const array) so future additions go through one source of truth and the value is shellcheck-safe under set -u. - update_checksums_file_has_required_metadata(file) parses the YAML with a hand-rolled bash parser (no python/yq dependency on the bootstrap path): - Walks indentation manually to find the "installers:" block - Tracks the current tool inside that block via tool_indent so the parser is robust to mixed-indent files - Records each tool -> {url, sha256} pair seen - Returns success only when every entry in update_required_checksum_tools is present with both keys - Comments and blank lines are skipped before any of the indentation checks so inline documentation is tolerated - refresh_checksums calls update_checksums_file_has_required_metadata on the temp file before the move-into-place step. On failure the cached file is preserved and a warning is logged, mirroring the prior fetched_valid handling. scripts/generated/internal_checksums.sh: regenerate the scripts/lib/update.sh sha256 entry to track the new content. tests/unit/lib/test_update.bats (+116/-): - New "refresh_checksums: rejects fetched yaml missing required tool metadata" test installs a fake checksums.yaml that omits the bun and ubs entries, runs refresh_checksums true, and asserts the cached file is left intact and the rejection message is logged. Existing tests adjusted to exercise both the success path (all tools present) and the failure path (one tool missing url) without touching unrelated assertions. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…er step Some users get confused at Step 9 about which user they should be SSH'd in as before pasting the installer one-liner. The installer auto-detects both root and the ubuntu user, but a few VPS images ship with non-standard root shells where root-launch fails immediately, leaving users stuck with no obvious next step. Add an info AlertCard at the top of the run-installer wizard page that: - shows both prompt shapes (root@ and ubuntu@) so users know what to expect - confirms the installer accepts either user - points failing-as-root users to Step 10 (Reconnect as Ubuntu) as a fallback before retrying Closes #275. Co-Authored-By: Claude <noreply@anthropic.com>

The earlier AlertCard pointed users at Step 10 (Reconnect as Ubuntu) as a fallback when the installer fails as root, but Step 10's flow is designed for *after* the installer has run — it ssh's as ubuntu using the SSH key that the installer set up. Following that advice on a fresh image lands the user on a step whose primary path can't work yet. Replace the Step 10 reference with concrete, immediately-actionable advice: open a fresh SSH session as a non-root user with sudo (commonly `ubuntu` or `admin` depending on the provider) using the provider's password, then re-run the command. Also clarify that Step 6's default leaves the user as root and the installer auto-detects which user it's running as. Co-Authored-By: Claude <noreply@anthropic.com>

Updated checksums for upstream installer scripts that have changed. Changed tools: mcp_agent_mail Trusted: mcp_agent_mail External: none Drift fixed: false 🤖 Generated by checksum-monitor workflow

…session The earlier "open a fresh SSH session as a non-root user" advice was impractical: most VPS providers don't expose a separate password for the ubuntu/admin user, so users typically can't actually SSH in as that user with the root password. The simpler, universally-correct fallback is `su - ubuntu` from the existing root session — root can switch to any user without a password, the action is a single command, and the failure mode is clear if the user doesn't exist (su prints "user does not exist"). Drops the misleading "(most VPS providers pre-create one named ubuntu or admin) using your provider's password" framing. Also picks up a small clarifying line about duplicate SSH key handling that was already in the working tree from a peer agent edit. Co-Authored-By: Claude <noreply@anthropic.com>

Previously the AlertCard hardcoded "ubuntu" in three places (the prompt example, the username, and the `su -` command). On VPS images using a different default user — Debian's `debian`, Amazon Linux's `ec2-user`, or any custom name the user typed in earlier wizard steps — the advice would tell users to switch to a user that doesn't exist on their box. The rest of this page interpolates `effectiveSSHUsername` (line 88: `sshUsername.trim() || "ubuntu"`), and `buildInstallCommand` passes `TARGET_USER="${safeUsername}"` to the installer so the user's choice is honored end-to-end. Use the same pattern in the fallback advice. Co-Authored-By: Claude <noreply@anthropic.com>

The production Vercel project was reporting Ready while serving only Vercel's catch-all 404. Local Vercel output confirmed the root config was publishing apps/web/.next as a static output directory with framework=null, which bypassed the Next.js builder entirely and generated a routing table with only a 404 fallback. Switch the root Vercel config away from static .next publishing and toward the Next.js framework preset. The actual Vercel project settings have also been updated to use apps/web as the Root Directory with the Next.js preset, so Git deployments consume apps/web/vercel.json and build the app as a real Next deployment. Add .next ignore patterns to the root and web Vercel ignore files so future CLI deploy attempts do not accidentally package stale or oversized local Next build artifacts. Verified with: vercel build --prod; cd apps/web && bun run type-check && bun run lint && bun run build; shellcheck install.sh scripts/**/*.sh packages/onboard/onboard.sh tests/e2e/test_new_tools_e2e.sh tests/vm/test_fresh_root_bootstrap_regression.sh; ubs .vercelignore apps/web/.vercelignore vercel.json

Fresh-eyes review found two related reliability defects in the web deployment/tooling layer. First, apps/web/scripts/vercel-ignore-build.sh could be run from apps/web but reasoned about trigger paths as if it were always at the repo root, and it did not treat root Vercel deployment config as build-triggering input. That meant a deployment-affecting root vercel.json or .vercelignore change could be skipped, leaving production stale or misconfigured. The script now normalizes to the Git repository root, uses exact matching for file triggers, keeps prefix matching only for directory triggers, and includes root Vercel config files in the trigger set. A new Bats regression covers app-directory execution, root config changes, and unrelated doc changes. Second, the web isolated type-check/build scripts copied tsconfig.json verbatim, including the shared .next/types and .next/dev/types include entries. Under concurrent builds, another Next process can rewrite or remove .next while the isolated type-check is running, causing false TS6053 missing-file failures despite ACFS_NEXT_DIST_SCOPE. The new prepare-isolated-tsconfig.mjs helper strips only shared .next/* include entries from temporary tsconfig copies before Next adds the scoped .next-<scope> entries, preserving isolation for parallel agents. Verified with: shellcheck install.sh scripts/**/*.sh apps/web/scripts/vercel-ignore-build.sh tests/unit/web/test_vercel_ignore_build.bats; bats tests/unit/web/test_vercel_ignore_build.bats tests/unit/lib/test_user.bats; cd packages/manifest && bun run generate --diff; cd apps/web && bun run type-check && bun run lint && bun run build; concurrent cd apps/web && bun run type-check, vercel build --prod, and ACFS_NEXT_DIST_SCOPE=audit-build-419493 bun run build:isolated; ubs apps/web/package.json apps/web/scripts/prepare-isolated-tsconfig.mjs apps/web/scripts/vercel-ignore-build.sh tests/unit/web/test_vercel_ignore_build.bats.

The fresh-eyes pass found that the ignored-build diagnostic introduced in the Vercel helper could trip set -euo pipefail when many unrelated files changed. The echo | head pipeline can return a SIGPIPE status, which flips a legitimate skip decision into a failing command and burns build time. Replace that pipeline with a printf | awk limiter that consumes input deterministically without relying on head closing the pipe. Add a Bats regression fixture with 200 unrelated documentation changes so the skip path stays covered under a large diff. Verification: shellcheck install.sh scripts/**/*.sh apps/web/scripts/vercel-ignore-build.sh tests/unit/web/test_vercel_ignore_build.bats; bats tests/unit/web/test_vercel_ignore_build.bats tests/unit/lib/test_user.bats; cd apps/web && bun run type-check && bun run lint && bun run build; vercel build --prod; git diff --check; UBS on touched files.

Generated installer scripts run in sensitive root and target-user contexts, so their helper for locating system binaries must not accept pathlike names. Recent manual hardening covered the hand-written resolver functions, but the generator template still emitted acfs_generated_system_binary_path without the same name validation. That left regenerated install and doctor scripts with weaker behavior than the reviewed hand-written helpers. Reject empty, dot, dot-dot, slash-containing, whitespace-containing, and other non-command names in the generated resolver before constructing absolute candidate paths. Regenerate all affected installer scripts from the manifest source instead of hand-editing generated output. Expand regression coverage so the shell audit includes generated install_all.sh and doctor_checks.sh, and tighten the TypeScript generator assertions so they distinguish exact unsafe TARGET_HOME fallback lines from the safe resolved-home assignment. Verification: shellcheck install.sh scripts/**/*.sh tests/unit/test_changelog_export_status.sh; cd packages/manifest && bun test; cd packages/manifest && bun run type-check; cd packages/manifest && bun run generate:diff; git diff --check; bash tests/unit/test_changelog_export_status.sh; direct generated helper unsafe-name probe.