Lucid Integration CI Gate

Overview

Build a secretless pull-request gate and a separately approved live verification lane for Lucid integrations.

Prerequisites

• The integration kind: REST API, Standard Import, editor extension, or data connector
• Repository ownership rules and sanitized fixtures
• Current Lucid documentation for every API version, scope, and package command used

Tool Discipline

Use Read, Glob, and Grep to inspect manifests, import archives, code, tests, and workflows. Use WebFetch only for current official Lucid pages. Use Write or Edit only within the approved repository scope.

Current Contract

• REST requests use Bearer authorization and a valid resource-specific Lucid-Api-Version.
• Standard Import archives contain document.json; their rendered result can change as the format evolves.
• Official extension builds use lucid-package; pull-request jobs do not need production tokens.

Authentication

Keep API keys, OAuth client secrets, access tokens, refresh tokens, authorization codes, and account tokens out of fork and pull-request jobs. A protected live lane may use only an approved secret, correct token type, least scopes, and exact redirect URI.

Instructions

1. Classify the integration and list its authoritative manifest, schema, API-version, and scope inputs.
2. Inspect every workflow and fixture with Read, Glob, and Grep.
3. Add schema and archive checks for Standard Import, including unique IDs, required pages, media limits, and path safety.
4. For extensions, run the documented build and bundle commands in a pinned runtime and verify the manifest requests only used scopes.
5. Mock REST responses by endpoint and version; cover 401, 403, 429, 5xx, malformed payload, and timeout behavior.
6. Keep fork jobs synthetic. Put any live smoke test behind protected-environment approval and cleanup.
7. Save a redacted receipt naming inputs, versions, checks, and remaining manual verification.

Approval Boundaries

Do not expose secrets to untrusted code, mutate real documents from fork CI, or treat mocks as proof of live access.

Output

Return integration kind, protected paths, checks, fixture provenance, secret exposure count, required contexts, live lane, cleanup, and residual risk.

Error Handling

Example

kind=standard-import; fixtures=3; fork-secrets=0; schema=pass; bundle=pass; live-lane=protected; result=pass

Resources

• Official documentation map

Next Steps

Recheck package releases, endpoint versions, scopes, branch protection, and cleanup before each production release.