Connect claim activation pipeline

[GsCommand]

Motivation

• Wire the claim frontend and backend into a real activation pipeline by persisting tenant public signer identity, verifying ENS TXT records, and reusing proven server-side steps (pinning → genesis) while keeping tenant private keys local.
• Provide operator/admin tooling and UI to observe and idempotently run safe activation steps without performing onchain ENS writes in this PR.

Description

• Persist activation and signer material with a migration db/migrations/008_claim_activation_pipeline.sql and store only public tenant signer fields plus a TXT package and agent card JSON inputs.
• Add/modify API endpoints: public intake now accepts managed_namespace / bring_your_own_ens signer data (api/claim/commandlayer-namespace.js), ENS TXT verification POST /api/claims/verify-signer-records (api/claims/verify-signer-records.js), claim status GET /api/claims/status (api/claims/status.js), tenant-proof verification POST /api/claims/verify-tenant-proof (api/claims/verify-tenant-proof.js), and an admin idempotent orchestrator POST /api/admin/run-activation-pipeline (api/admin/run-activation-pipeline.js) that reuses existing pin/genesis handlers.
• Introduce helper library lib/claims/signer-records.js for building/resolving/comparing the four required TXT records and wire resolver usage through existing verifier code; expose safe resolver hooks from lib/verifyReceipt.js.
• Update UI: public/claim.html now (a) warns that the private signing key is local and never transmitted, (b) requires download/ack before continuing, (c) submits tenant public signer fields + TXT package + card JSON, and (d) displays a persisted activation pipeline with a "Verify ENS Records" action; public/admin/claims.html shows signer identity, TXT package, managed ENS intent and tenant-proof status.
• Rejects any request containing private-key material and sanitizes agent card inputs before persistence.

Testing

• Ran unit/integration test suite with npm test (all tests passed: 137 tests, 0 failures) and added tests/claim-activation-pipeline.test.js covering claim submission persistence, ENS record verification, mismatch/missing cases, idempotent orchestration, status model, and tenant-proof signer matching.
• Ran link checks with npm run check:links and example checks cd examples/webhook-auto-verify && npm run check, both succeeded.
• Verified server-side JS syntax for new endpoints with Node --check during development; automated tests exercise the new endpoints and helper logic successfully.

Files changed (high level): api/claim/commandlayer-namespace.js, api/claims/verify-signer-records.js, api/claims/status.js, api/claims/verify-tenant-proof.js, api/admin/run-activation-pipeline.js, api/admin/claims.js (small additions), lib/claims/signer-records.js, lib/verifyReceipt.js (exports), public/claim.html, public/admin/claims.html, db/migrations/008_claim_activation_pipeline.sql, and tests/claim-activation-pipeline.test.js.

Persisted public signer fields: activation_mode, tenant_signer_ens, tenant_signer_public_key, tenant_signer_kid, tenant_signer_canonicalization, tenant_signer_record_status, tenant_signer_records_verified_at, tenant_signer_records_network, tenant_signer_verification_error, and tenant_signer_txt_records.

Supported activation/status values: signer records: records_generated, records_pending, records_verified, records_mismatch, records_unavailable; managed ENS publication (prepared for later): not_started, awaiting_payment, ready_for_operator, published, verified, failed; tenant proof: not_submitted, verified, invalid.

What became automatic in this PR: an authenticated admin/internal orchestrator can idempotently advance already-paid claims through existing IPFS pinning of public agent cards and genesis receipt generation while avoiding ENS writes.

What remains manual / intentionally deferred: tenant private keys remain local (never stored/transmitted), ENS TXT publication and managed onchain subname creation are deferred and not executed in this PR, and tenant action proof submission remains an operator/tenant-triggered checkpoint (this PR provides verification endpoint and stores the result).

Next PR (exact intent): implement managed subname creation and onchain TXT publication with operator transaction model, parent-ownership/resolver authority checks, gas handling, idempotency and retry/failure recovery logic (this PR only stores the public TXT package and readiness status).

---

Codex Task

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
commandlayer-commandlayer-org	Ready	Preview, Comment	May 30, 2026 2:45am
commandlayer-org	Ready	Preview, Comment	May 30, 2026 2:45am
commandlayer-org111	Ready	Preview, Comment	May 30, 2026 2:45am