codex/git-remote-and-agent-polish

The ph CLI client's DEFAULT_BASE_URL changes from https://news.pikachat.org to https://git.pikachat.org, and the corresponding test fixture is updated to match.

In auth.rs, the hardcoded Nostr NIP-98 verify URL in the test switches to the new domain. The browser-side base.html template is also fixed: instead of using window.location.href (which could include query strings or fragment paths), it now constructs the verify URL explicitly via new URL('/news/auth/verify', window.location.origin), making auth work correctly regardless of the page the user is on.

The Caddy reverse-proxy in builder.nix now serves git.pikachat.org as the primary virtual host and returns a 410 Gone response for the old news.pikachat.org hostname.

Documentation in README.md and forge-hosted-manual-qa.md is updated to reference the new canonical Git remote git@git.pikachat.org:pika.git and the web UI at https://git.pikachat.org/news.

A new schedule_ci_pass_with_updates entry point is added alongside the existing run_ci_pass_with_updates. The key difference is in schedule_ci_pass_with_timing_at: after claiming lane jobs, it calls launch_claimed_job for each one, which spawns a thread::spawn that executes the lane and notifies a tokio::sync::Notify when done. This lets the scheduler return its CiPassResult immediately without waiting for execution to complete.

To compute how many new jobs to claim without tracking active worker threads in-process, a new next_scheduler_claim_limit function queries the database directly. It relies on Store::count_running_ci_lane_runs, a new method that counts rows with status = 'running' across both branch_ci_run_lanes and nightly_run_lanes tables. The claim limit is ci_concurrency - running_count.

In web.rs, the background CI pass switches from run_ci_pass_with_updates to schedule_ci_pass_with_updates, passing a clone of the poll_notify Arc so that finishing threads can wake the main loop for follow-up scheduling.

A comprehensive integration test scheduler_pass_returns_while_running_lane_does_not_block_later_claims validates the core property: a first scheduler pass launches a slow lane, a second pass immediately launches a fast lane without waiting for the slow one, and both eventually succeed.

Two new AtomicBool fields are added to AppState: mirror_requested signals that a mutation (merge or close) wants an immediate mirror push, and mirror_running acts as a lock to prevent overlapping mirror operations.

run_scheduled_mirror_pass checks mirror_requested and uses compare_exchange on mirror_running to acquire exclusive access. If acquired and a force was requested, it calls the full mirror::run_mirror_pass; otherwise it falls back to the background mirror pass. The flag is cleared on release regardless of outcome.

The merge_handler and close_handler both set mirror_requested to true before waking the poll loop, ensuring the next background tick picks up and pushes to the GitHub mirror immediately.

The admin manual-sync endpoint now also gates on mirror_running with compare_exchange, returning a 409 Conflict if a sync is already in progress. All exit paths in the handler release mirror_running to avoid deadlocks.

In pika-news.nix, a new git system user is created in the same pika-news group, with git-shell as its shell. This restricts the user to Git-only SSH operations. The bare repo bootstrap script now sets ownership to git:pika-news instead of pika-news:pika-news, and explicitly handles .githooks directory permissions so that forge-installed hooks remain owned by the service user and executable.

An additional systemd.tmpfiles rule ensures the state directory permissions are re-applied on boot with z (verify/fix mode).

In builder.nix, SSH authorized keys are refactored into let bindings (justinAuthorizedKeys, benAuthorizedKeys, paulAuthorizedKeys) and the git user receives the union of all three key lists, granting all team members push access through the forge-native SSH path.

AGENTS.md gains two new sections. The top-level preamble now states that canonical Git lives on git.pikachat.org and instructs agents to prefer the forge remote and ph for CI/merge/close actions. A new "Forge Workflow" section reinforces the same points with concrete commands.

A new .agents/skills/land/SKILL.md provides a comprehensive agent skill for landing branches. It covers remote policy (inspect before changing), the default landing flow (fetch, rebase, push, ph wait, ph merge), when to use sibling worktrees, ph command reference, failure handling guidance (ignore CodeRabbit/Devin noise, focus on forge CI), and a final-handoff checklist.

The agent-brief script adds ph --help output to the brief so that agents see the forge CLI's capabilities at session start.

A new 352-line roadmap document is added at todos/pika-git.md. It is organized into several major sections:

Product Direction — The forge should optimize for quick branch understanding, merge confidence, and agent/human review loops rather than being a generic GitHub clone.

Review UI Direction — References specific historical commits that had the best review UI features (file sidebar, resizable chat panel, diff presentation) and calls for restoring them while separating CI detail onto a dedicated page.

CI UX Direction — Defines the compact color-coded CI summary for the branch page (green/yellow/red) and what belongs on the dedicated CI details page.

Anti-Stall CI Model — Specifies required scheduler properties: a failed lane must not block unrelated runnable lanes, capacity shortages must be explicit, and target-specific failures must stay scoped. Defines the pika-git vs pikaci responsibility split for scheduling, leases, timeouts, and failure classification.

Operational Recovery Tooling — Lists UI and ph recovery actions (rerun lane, rerun suite, recover stale work, inspect queue reasons) as core requirements for dogfooding.

Architecture Direction — Proposes forge_runtime, forge_service, typed shared models, and domain-split persistence as the target module boundaries.

Phase 1 — Defines five exploration workstreams (review UI recovery, operational recovery, runtime boundaries, pika-git/pikaci boundary, legacy/naming) with explicit questions each must answer before phase 2 implementation begins.

The pika-news README now documents the forge_repo.hook_url config field, clarifying that it is the internal hook target used by the forge-managed bare-repo Git hooks—not a GitHub webhook endpoint. A new note states explicitly that GitHub repo webhooks are not required for normal forge operation.

The manual QA checklist in forge-hosted-manual-qa.md adds step 6 to the admin/mirror section: testers should not expect a GitHub repo webhook to drive the mirror flow, since canonical ingestion comes from forge-managed bare-repo hooks.