GCA Access Operations Runbook

1. Public API Check

Run python3 tools/check_gca_registration_api.py --public-only --timeout 30 to verify health, CORS, and admin-read rejection without reading user records.

2. Admin Export

Run python3 tools/export_cloudflare_email_registrations.py --limit 100 --output .gca_access_data/cloudflare_email_registrations_export.json from the operator machine only.

3. Combined Sync

Run python3 tools/run_gca_registration_ops.py --limit 100 --data-dir .gca_access_data to sync D1 records, apply suppressions, export contact CSVs, and write the summary JSON.

4. Local Ledger

Expected local ledger output: .gca_access_data/email_registrations.jsonl. It stays ignored and is not committed to the public repository.

5. Contact Exports

Internal CSV: .gca_access_data/gca_email_contacts.csv. External-safe CSV: .gca_access_data/gca_email_contacts_public_redacted.csv.

6. Ops Summary

The combined pipeline writes .gca_access_data/gca_registration_ops_summary.json with counts, suppression status, output paths, and boundaries.

1. Intake Triage

Accept only non-sensitive account intent, public wallet address, declared GCA balance, program intent, public transaction references, GCA Member holding start date, and member evidence note from the gca_member_preregistration_v2 packet.

2. Identity Check

Confirm Base Mainnet chain ID 8453 and official contract 0x3197c42f4a06f7be32a9a742ac2a766f0ff682c6.

Device Status Recovery

Never ask the user to send a device status key. The member first opens a recovery request on the member-access page, which pre-commits a new browser key and returns the same response whether or not the account matches. Verify control of the exact registered mailbox, then run tools/approve_cloudflare_account_recovery.py with all required acknowledgements. Send the generated mode-0600 recovery packet only to that registered mailbox. The one-time credential expires after 24 hours; completion invalidates the old key without changing the account, credits, member records, wallet balance, or on-chain assets.

3. Wallet Balance Check

Use read-only eth_call and ERC-20 balanceOf. Do not request signatures or transactions for balance reads.

4. Holding Period Review

Treat holdingStartDate and evidenceTxHash as supporting preview evidence. The production approval route also reconstructs the observed 30-day GCA transfer history from a safe Base snapshot, Base Blockscout, and recent wallet-specific Base RPC logs. Approval fails closed unless the history is complete, internally consistent, and the observed minimum balance is at least 1,000,000 GCA.

5. Eligibility Decision

Use tools/review_cloudflare_member.py to record an approved, rejected, or needs-more-information decision through /gca/member-reviews. Successful approval writes append-only gca_holding_verification_v1 evidence and activates member status only; it does not authorize or send the 10,000 GCA benefit.

6. Support Reply

Reply with status, next step, and public links from a full internal export only. A redacted-public export is for reviewer evidence handoff and must not be used as a contactable support queue. Do not promise approval timing, platform listing, price support, audit approval, or trading results.

7. Ledger Handoff

Inspect the active member and linked holding evidence before any manual 10,000 GCA reserve-wallet transfer.

8. Transfer Evidence

After the manual transfer confirms, use tools/record_cloudflare_member_benefit_transfer.py with the protected /gca/member-benefit-transfers route and gca_member_benefit_transfer_v1 packet. The Worker requires a successful safe-block receipt, the official reserve sender, approved recipient, GCA contract, and exact 10,000 GCA amount. It never initiates or signs a transfer.

9. Service Request Triage

Users with a valid device key submit through /gca/account-service-requests. Before review, the same account may cancel a queued request through /gca/account-service-requests/cancellations. Use tools/review_cloudflare_service_request.py for append-only decisions. For needs_more_information, publish one non-sensitive memberPrompt; the account can append a bounded response through /gca/account-service-requests/follow-ups, then the request returns to manual review. Read full responses only through the protected /gca/service-request-followups route. Never collect credentials or create trading permission.

10. Reviewed Delivery

Only an approved request can be marked delivered. Confirm manual completion and credit settlement in the same operator tool, and supply a non-sensitive delivery reference. The Worker uses the server catalog unit and atomically records one linked usage, deduction, review, and delivered status; retries cannot deduct twice.

11. Platform Follow-Up

When a reviewer asks for more information, send public URLs only and keep pool, contract, status, and claim boundaries consistent.

12. Review Package Handoff

When a reviewer asks for local member-ledger evidence, export only the redacted-public package, verify packageDigestSha256, and use the Platform Replies local review package template. Never send a full-local package externally.

13. Review Chain Checkpoint

After continuity verification and a meaningful review batch, export a chain-head receipt with .venv/bin/python tools/create_gca_support_review_checkpoint.py --output ~/Documents/gca-support-review-checkpoint.json and retain it outside the ledger directory.

14. Closure

Before closing, run .venv/bin/python tools/verify_gca_support_review_audit.py. Close the record only after continuity passes and status, evidence reference, reviewer note, and next public link are recorded without secrets.

1. Token-Protected Export

Run .venv/bin/python tools/run_gca_member_access_ops.py --base-url https://gca-registration-api.gcagochina.workers.dev --limit 100 --redact none --summary-output .gca_access_data/gca_member_access_ops_summary.json.

2. Local Reports

Expected outputs include .gca_access_data/cloudflare_member_access_export.json, account/wallet/credit/service-request/credit-usage/member CSVs, and .gca_access_data/member_access_report/gca_member_access_summary.json.

3. Support Queue

The pipeline writes .gca_access_data/member_access_report/gca_member_support_queue.csv and its summary so replies can be reviewed manually before sending.

4. Holding Evidence

For 30-day member review evidence, rerun with --include-holding-report --holding-no-live-read when using existing snapshots, or run live read-only balance checks only on operator hardware. The summary output is .gca_access_data/member_access_report/gca_holding_period_summary.json.

5. Digest Refresh

After member ops, rerun .venv/bin/python tools/run_gca_daily_ops.py --build-digest --update-public-status so the local operator digest shows member counts without exposing user records.

6. Credit Usage Ledger

Do not write credit usage directly for account requests. Mark the approved request delivered through /gca/service-request-reviews; the Worker creates the linked credit usage and before/after balance exactly once.

7. Service Request Queue

The protected service_requests queue stores request scope without deduction. A more-information review must publish a safe member prompt; use the protected service-request-followups read to inspect the account response. Public history returns only prompt, time, and count. The workflow requires approval before delivery.

8. Member Review Decision

After reviewing public evidence, run .venv/bin/python tools/review_cloudflare_member.py --help and use the required production-write confirmation. Approval also requires the explicit evidence-reviewed confirmation. The command never prints the admin token or sends a wallet transaction.

9. No Automatic Transfer

The member ops pipeline never sends GCA. Any 10,000 GCA member benefit remains manual reserve-wallet processing after review.

No Sensitive Data

Reject Private key or seed phrase, Exchange API secret or withdrawal permission, one-time code, recovery phrase, Custody request, fund-transfer request, or live trading instruction.

No Manual Override

Manual support cannot override on-chain wallet-balance verification, release gates, credit ledger activation, or member ledger activation.

Public Boundary

Every response should keep GCA described as concept-stage product buildout with live account intake and eligible ledger records, while live trading and automatic token-benefit transfer remain off.

Redacted Package Only

External reviewer handoff must use the redacted package and verified digest. Full-local records remain internal operator evidence.

No Replies From Redacted Exports

Public-redacted exports are evidence handoff artifacts only. Run the internal operator export before sending account-specific support replies.

Local Continuity Only

The support-review SHA-256 chain detects edits, reordering, and interior deletion while a later chained record remains. Without an independently retained head, it cannot prove that the tail was not truncated or the complete ledger was not replaced. It is not signed, externally anchored, immutable, a production approval system, or a third-party audit.

An unsigned checkpoint export is available for separate retention. Comparing an unchanged receipt later can detect truncation below or a different lineage before that saved head. No public checkpoint, digital signature, independent authenticity proof, or external timestamp is currently claimed.