Revise C3 with endpoint connectivity validation details

Updated C3 to include endpoint connectivity validation details and clarified the conditions under which the validation was executed. Added notes on the observed HTTP responses and the implications for future interactions with the API.

Author: GodSpeed313

docs/m7_operator_go_checklist.md

@@ -139,7 +139,7 @@ as an unrecorded verbal/mental decision.
 |---|---|---|---|---|
 | **C1.** Live CAPTCHA wiring plan completed — not required for §A's preliminary review, but required before wiring begins | Complete | Plan recorded as its own dated artifact, `docs/m7_c1_live_captcha_wiring_plan_2026-08-13.md`, following the GO-1 precedent of a dated record rather than a row-embedded decision. It amends no numbered section of this checklist, of `docs/m7_moltbook_transport_boundary_and_deployment_spec.md` or its Implementation Notes, of `docs/moltbook_api_spec.md`, or of any ruling in `docs/`. **Scope ruled broad by operator on 2026-08-13:** C1 settles the semantic contract C2 implements, rather than describing the method by which C2 would discover it — the stated reason being that a narrow C1 would make the first live CAPTCHA submission the place where an unconfirmed platform response is interpreted for the first time, which is the decision this preparation gate exists to prevent. The plan settles: (§3.1) the classification principle generating the mapping — `CONFIRMED_*` only where the response establishes what happened to *this* challenge, `AMBIGUOUS` as the positive statement that a response is not evidence either way; (§3.2) detection precedence across the HTTP-status and response-envelope axes, needed because the 2026-07-21 capture pins envelopes for the success and incorrect-answer cases but not the HTTP status accompanying the latter, and pins statuses for 410/404/409 without their bodies; (§3.3) the eleven-row response-condition table, each row carrying its own evidence provenance and an explicit not-live-confirmed marker; (§3.4) HTTP 409 as `AMBIGUOUS`, treated as a first-class decision rather than a table entry, on the reasoning that "code already used" is consistent with a prior verification having *succeeded*, so classifying it as `CONFIRMED_FAILURE` would stamp `NOT_PUBLISHED` on live content and suppress the §C5 correction procedure — and that this classification stands independently of the retry ruling, since a lost response (row C1-10) produces the same observable 409 with no deliberate retry anywhere; (§4) the residual rule, unenumerated responses resolving to `AMBIGUOUS` with no silent coercion and no exception-raising, the latter because raising would make `AMBIGUOUS` unreachable through the route most likely to produce it and would contradict the three-status contract the plan settles; (§5) no retry at any layer, scoped deliberately below the HTTP client because adapter-level retry defaults would silently alter the semantics fixed at §3.3; (§6) `AMBIGUOUS` as final as a classification with its disposition after `verify()` recorded as unresolved; (§7) the requirement that `CaptchaAttemptRecord` identify which §3.3 condition matched or that none did, mandatory rather than nullable, so that predicted-ambiguous and residual-ambiguous outcomes remain distinguishable; (§8) ten C2 acceptance criteria; and (§9) five C2 stop conditions, including that any unanswerable question about `/verify` behaviour is a stop and never a reason to probe (GO-1 §5.3, §C3 binding wording). **Two items are deliberately left unresolved and are recorded as such rather than settled:** the disposition of an `AMBIGUOUS` outcome after `verify()` returns — the outcome is recorded on `TransportResult` (`moltbook/transport.py:1366–1378`) but nothing consumes it, no reconciliation and no escalation, where its send-layer counterpart `AMBIGUOUS_WRITE` routes to transport spec §9 — which is an architectural question for its own ruling, carried as C2 acceptance criterion 7 rather than resolved inside C1; and (§10) two items identified for operator attention, the expiry-counter asymmetry between the locally-declined and platform-confirmed routes, and `RateLimitInfo` at the verify seam. The plan is **version-bound to the 2026-07-21 `moltbook.com/skill.md` capture** and does not inherit forward across a material change to it: per the transport spec's own statement, "nothing has yet been confirmed against a live write," and the plan claims authority over the interpretation, not over the platform. **This row attests that the wiring plan required before C2 exists, is recorded, and has been read; it does not attest that its classifications have been empirically validated, and §2 of the plan states plainly that none of them have.** **This attestation is version-bound and confers no authority over the document's future contents.** No code was written, no transport behaviour changed, and `POST /api/v1/verify` was not called. | Kevin Brown | 2026-08-13 18:28 EDT |
 | **C2.** `submit_captcha_fn` wired live against real `POST /api/v1/verify`; `captcha_verifier`/`submit_captcha_fn` both-or-neither invariant confirmed at construction (Note E item 7); reviewed | Complete | `moltbook/transport.py` (+245) and `tests/test_moltbook_transport.py` (+428) at `ce84d22`, tree clean. `submit_captcha_fn` wired against real `POST /api/v1/verify`; `captcha_verifier`/`submit_captcha_fn` both-or-neither invariant confirmed at construction (Note E item 7). Classification precedence implemented per C1 §3.2 as read by **Erratum 1** (`docs/m7_c1_wiring_plan_erratum_1_2026-08-17.md`, LOCKED, signed 2026-08-17 00:43 EDT), whose ratified reading is that §3.2 rule 1's parenthetical **should read** "§3.3 rows 3–9" rather than "rows 3–7", so that the enumerated rows C1-8 (400) and C1-9 (500) are matched by rule 1 rather than by no rule at all. The erratum is filed instead of an edit; C1's locked text is unchanged and no row's outcome differs under either reading. Suite green: **647 passed, 7 xfailed**, verified by run at `ce84d22` with a clean tree, not recalled. **This row attests that the required artifacts exist at the cited commit and that the suite is green; it does not attest to a reading of the implementation itself.** | Kevin Brown | 2026-08-20 00:19 EDT |
-| **C3.** Endpoint connectivity validated — see wording below; **no governed post/reply and no synthetic CAPTCHA submission** issued solely as a connectivity probe | Complete | Validation recorded as its own dated artifact, `docs/m7_c3_endpoint_connectivity_validation_2026-08-21.md`, following the C1 precedent of a dated record rather than a row-embedded decision — the shape chosen by the operator on 2026-08-21 in preference to C2's row-only form. It amends no numbered section of this checklist, of `docs/m7_moltbook_transport_boundary_and_deployment_spec.md` or its Implementation Notes, of `docs/moltbook_api_spec.md`, or of any ruling in `docs/`. **Executed once at 2026-08-21 19:10 UTC against the live platform, transport at `c1eb9ba`, three requests total, no retries and no second run.** The artifact's §2 derives the permitted operation set from §C3's binding wording — the two documented non-publishing reads, and nothing else. Observed: an unauthenticated redirect check on `GET /api/v1/agents/status` returned HTTP 401 with no `Location` and no redirect, confirming the path does not redirect before the credential is attached to it; the authenticated `GET /api/v1/agents/status` returned HTTP 200 with body `status: "claimed"`, yielding `EligibilityState.CLAIMED`; and `GET /api/v1/posts` returned HTTP 200 with a cursor-paginated body of 20 items. All four steps matched the prediction recorded at §4.7 of the artifact **before** the run, and the method was drafted and shown to the operator before any request was issued. **No governed post or reply was issued, no synthetic CAPTCHA submission was made, and `POST /api/v1/verify` was not called** — the probe was constructed with `captcha_verifier` and `submit_captcha_fn` both absent, which Implementation Note E's fail-closed invariant expressly permits, so it had no CAPTCHA submission capability wired into it at all rather than merely declining to use one. **This row attests that the two endpoints in the permitted set answered and that this credential authenticated as a claimed agent at that moment. It does not attest that a governed post will publish, that the CAPTCHA path works, that any endpoint outside that set is reachable, or that the credential will still be valid at §E.** Six items are recorded at §6 of the artifact for their own rulings rather than settled here; two are material. First: `check_eligibility()` returns `PENDING_CLAIM` for any response whose body lacks `status: "claimed"`, a 401 error envelope included, while `health_check()` reports `TransportOutcome.SUCCESS` unconditionally and discards the `HTTPResponse` — so a dead credential and a live unclaimed one are the same value on the transport's own return, and `EligibilityBlocked` would report an authentication failure as a claim problem. C3 recorded the raw HTTP status through a pass-through recorder to see past this; the underlying behaviour is unchanged by this row. Second: the live rate-limit surface is not the one `docs/moltbook_api_spec.md` §5 describes — twelve headers were returned, including a tiered short-medium-long family the transport does not parse and whose tightest window (30) is therefore invisible to `RateLimitInfo`; the generic `x-ratelimit-limit` was 60 on `/agents/status` and 200 on `/posts` in two calls 200ms apart, so it is per-endpoint rather than the flat 60 per 60s §5 documents; and `x-ratelimit-reset` is an epoch timestamp while the tiered resets are deltas, one header family carrying two value formats. Recorded, not corrected: two endpoints on one credential at one moment is not a sufficient basis for rewriting a documented limit table. **This attestation is version-bound to the transport at `c1eb9ba` and to the 2026-07-21 `skill.md` capture, describes one moment rather than a standing property of the platform, and confers no authority over the artifact's future contents.** |  |  |
+| **C3.** Endpoint connectivity validated — see wording below; **no governed post/reply and no synthetic CAPTCHA submission** issued solely as a connectivity probe | Complete | Validation recorded as its own dated artifact, `docs/m7_c3_endpoint_connectivity_validation_2026-08-21.md`, following the C1 precedent of a dated record rather than a row-embedded decision — the shape chosen by the operator on 2026-08-21 in preference to C2's row-only form. It amends no numbered section of this checklist, of `docs/m7_moltbook_transport_boundary_and_deployment_spec.md` or its Implementation Notes, of `docs/moltbook_api_spec.md`, or of any ruling in `docs/`. **Executed once at 2026-08-21 19:10 UTC against the live platform, transport at `c1eb9ba`, three requests total, no retries and no second run.** The artifact's §2 derives the permitted operation set from §C3's binding wording — the two documented non-publishing reads, and nothing else. Observed: an unauthenticated redirect check on `GET /api/v1/agents/status` returned HTTP 401 with no `Location` and no redirect, confirming the path does not redirect before the credential is attached to it; the authenticated `GET /api/v1/agents/status` returned HTTP 200 with body `status: "claimed"`, yielding `EligibilityState.CLAIMED`; and `GET /api/v1/posts` returned HTTP 200 with a cursor-paginated body of 20 items. All four steps matched the prediction recorded at §4.7 of the artifact **before** the run, and the method was drafted and shown to the operator before any request was issued. **No governed post or reply was issued, no synthetic CAPTCHA submission was made, and `POST /api/v1/verify` was not called** — the probe was constructed with `captcha_verifier` and `submit_captcha_fn` both absent, which Implementation Note E's fail-closed invariant expressly permits, so it had no CAPTCHA submission capability wired into it at all rather than merely declining to use one. **This row attests that the two endpoints in the permitted set answered and that this credential authenticated as a claimed agent at that moment. It does not attest that a governed post will publish, that the CAPTCHA path works, that any endpoint outside that set is reachable, or that the credential will still be valid at §E.** Six items are recorded at §6 of the artifact for their own rulings rather than settled here; two are material. First: `check_eligibility()` returns `PENDING_CLAIM` for any response whose body lacks `status: "claimed"`, a 401 error envelope included, while `health_check()` reports `TransportOutcome.SUCCESS` unconditionally and discards the `HTTPResponse` — so a dead credential and a live unclaimed one are the same value on the transport's own return, and `EligibilityBlocked` would report an authentication failure as a claim problem. C3 recorded the raw HTTP status through a pass-through recorder to see past this; the underlying behaviour is unchanged by this row. Second: the live rate-limit surface is not the one `docs/moltbook_api_spec.md` §5 describes — twelve headers were returned, including a tiered short-medium-long family the transport does not parse and whose tightest window (30) is therefore invisible to `RateLimitInfo`; the generic `x-ratelimit-limit` was 60 on `/agents/status` and 200 on `/posts` in two calls 200ms apart, so it is per-endpoint rather than the flat 60 per 60s §5 documents; and `x-ratelimit-reset` is an epoch timestamp while the tiered resets are deltas, one header family carrying two value formats. Recorded, not corrected: two endpoints on one credential at one moment is not a sufficient basis for rewriting a documented limit table. **This attestation is version-bound to the transport at `c1eb9ba` and to the 2026-07-21 `skill.md` capture, describes one moment rather than a standing property of the platform, and confers no authority over the artifact's future contents.** | Kevin Brown | 2026-08-21 15:56 EDT |
 | **C4.** First-post runbook finalized (step-by-step execution script for §E below) | | | | |
 | **C5.** Published-Outcome Correction and Withdrawal Procedure finalized — must explicitly distinguish: delete (when supported), edit/correction (when supported), corrective follow-up (when neither is available), freeze-and-escalation (§9), and audit preservation. This is not a "rollback" in the atomic-reversal sense — most external APIs offer no such thing, and the procedure must not imply otherwise | | | | |