Self-acceptance wave-1: post-deploy live probe of the published site, auto-file defect issue on failure

[loning]

Parent: self-drive master umbrella (fkst-packages#139), pillar C wave-1. Site umbrella: #2.

Motivation (production evidence)

After waves 1 and 2 of the official site merged, a human verified the deployment by curl-probing the live pages (/, /zh/, /architecture.html, /doctrine.html). Self-acceptance means the system probes its own deployed artifact and converts a broken deploy into a defect issue — CI greenness does not prove the published site renders.

Scope (tight)

1. New flat package packages/site-probe/ (or a department inside site-board if conformance favors it — implementer's choice, justify in PR):
   • cron raiser (e.g. every 30m) → probe_scan department.
   • Reads the canonical page list from one place: site/probe-manifest (a tracked plain-text file, one URL path per line, seeded with /, /zh/, /architecture.html, /doctrine.html, /zh/architecture.html, /zh/doctrine.html).
   • For each path: curl -sL -o /dev/null -w '%{http_code}' against https://chronoaiproject.github.io/fkst-website — non-200 = failure (curl via exec_sync, mocked in tests; unmocked external commands fail closed).
2. On any failure: raise github-proxy.github_issue_create_request with a defect issue (title includes the failing paths; body includes status codes and probe time), deduped via an idempotent marker/cache key per (path set, day) so a persistent outage files ONE issue, not one per tick.
3. On success: structured greppable log line only (PROBE ok paths=N).
4. Dry-run posture: issue creation only when FKST_GITHUB_WRITE=1 (existing proxy behavior); probe itself is read-only.

Must keep (DELETE NOTHING ELSE)

• No changes to site/ pages themselves or pages.yml.
• Payload constitution: the issue body carries status codes and paths (small control data), no page content.
• Fail-closed: curl/network errors count as probe failure of that path, but a fully-failed probe sweep (all paths erroring, e.g. local network down) files NOTHING and logs a skip — do not convert babysitter-side network flakiness into site defect issues (lesson: a transient empty git ls-remote once caused a false kill).

Acceptance

• Tests: all-200 → no issue request + ok log; one 404 → exactly one issue request with path and code, idempotent across repeated ticks; all-paths-network-error → no issue request + skip log.
• scripts/run.sh test + scripts/run.sh check green.

⟦AI:FKST⟧

[loning]

github-devloop intake decision: enable

Reason:
Implementation request for read-only probing plus gated issue creation; no required secrets, destructive action, or human approval.

[loning]

github-devloop thinking: consensus started

[loning]

github-devloop convergence round 0 — 三方未达成共识，收窄中

收窄问题: Should wave-1 use a new site-probe scheduled package with deduped GitHub issue creation, or first prove the acceptance loop through existing CI/site-board machinery with probe logs only?

三方立场:

• minimal: abstain — Minimal angle cannot approve yet because the proposal adds a new cron package plus GitHub issue filing before proving the smallest viable acceptance loop; approval would need either evidence that an existing scheduled department cannot host this probe, or a reduced first scope that only probes the manifest and emits greppable success/failure logs, with issue creation deferred until noisy-network and dedup behavior are validated.
• structural: approve — The proposal preserves boundaries by adding an explicit site-probe package/department, reading paths from a tracked manifest, using github-proxy for issue creation, and keeping payloads to small control data; the success/failure/skip rules define a maintainable data flow with deduped defect emission and fail-closed handling for babysitter-side network failures.
• delete: abstain — The need to verify the published site is real, but this adds a new scheduled package, live network curl behavior, idempotency state, and GitHub issue creation surface for four static pages; from the delete angle this should first prove why an existing CI/GitHub scheduled check or existing site-board department cannot cover the probe with less durable machinery.

⟦AI:FKST⟧

[loning]

github-devloop convergence round 1 — 三方未达成共识，收窄中

收窄问题: Should wave-1 be reduced to manifest-driven live probe logs through existing CI/site-board machinery, deferring scheduled package and deduped GitHub issue creation until probe noise and hosting needs are proven?

三方立场:

• minimal: abstain — Minimal angle is not ready to approve a new scheduled package plus deduped GitHub issue creation for wave-1; first prove the smallest viable acceptance loop through existing CI/site-board machinery with the tracked manifest, live probe, and greppable ok/failure/skip logs, then approve issue filing only after evidence shows scheduled hosting, network-noise handling, and dedup behavior are needed and stable.
• structural: approve — Structurally this preserves clean boundaries: probing is an explicit site package or department, page scope comes from a tracked manifest, GitHub mutation stays behind github-proxy and FKST_GITHUB_WRITE, payloads remain small control data, and the success/failure/all-network-error split plus per-day path-set dedup gives a maintainable data flow rather than ad hoc deploy babysitting.
• delete: abstain — The live published-site probe is justified, but wave-1 still overbuilds it: a new scheduled package plus curl execution, dedup state, and GitHub issue creation is too much durable surface before the repo proves a simple acceptance loop through existing CI or site-board machinery with manifest-driven probe logs only.

⟦AI:FKST⟧

[loning]

github-devloop decision: approve
三方裁决: minimal=approve structural=abstain delete=approve

minimal:
Approve the narrowed wave-1 only: manifest-driven live probes through existing CI/site-board machinery with greppable ok/failure/skip logs, while deferring the scheduled package, dedup state, and GitHub issue creation until real probe runs show noise levels, hosting cadence, and issue-filing need.

structural:
Structurally, the reduced wave-1 direction is cleaner than the original because manifest-driven live probe logs can preserve the site/site-board boundary while avoiding premature GitHub mutation state, but it is not yet approvable until the proposal pins the owning execution surface, log schema, failure classification, and contract for how CI/site-board consumes site/probe-manifest without introducing an implicit runtime interception path.

delete:
Reduce wave-1 to manifest-driven live probe logs through existing CI/site-board machinery; this preserves the real acceptance signal while deleting the new scheduled package, dedup state, and GitHub issue creation surface until probe noise, hosting cadence, and failure semantics are proven.

⟦AI:FKST⟧

[loning]

github-devloop implementation started

Worktree: /tmp/website-sv-rt.qf5JWt/worktrees/devloop-ChronoAIProject-fkst-website-11-0557464292
Branch: devloop/issue/ChronoAIProject/fkst-website/11/ready-consensus-github-devloop-issue-ChronoAIProject-fkst-website-11-2026-06-10T08-43-17Z-loop-2-0557464292
Head: 7cf24d1
Base branch: integration
Base head: 73f0b15

[loning]

github-devloop PR opened: #12