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

Lucid Integration Error Triage

Overview

Identify the failing layer before changing credentials, scopes, documents, packages, or connector state.

Prerequisites

• A redacted request ID, timestamp, status, integration kind, endpoint or command, and API/package version
• Expected token type and scopes from the exact official operation page
• Permission to inspect the relevant repository and Lucid project

Tool Discipline

Use Read, Glob, and Grep for local evidence, WebFetch for official Lucid contracts and status, and Write or Edit only for approved fixes or redacted receipts.

Current Contract

• 401 can reflect invalid or revoked credentials; 403 can reflect token type, scope, resource access, or endpoint rules.
• 429 behavior and limits are endpoint-specific; never substitute a pack-wide quota.
• Standard Import, REST resources, editor extensions, and data connectors have different failure surfaces.

Authentication

Never collect raw tokens, secrets, authorization codes, cookies, or complete request headers. Confirm only credential class, grant, scope names, issuer environment, rotation state, and a redacted fingerprint.

Instructions

1. Establish the last known good time and whether Lucid status reports an incident.
2. Classify the layer: network, auth, authorization, version, payload, document permission, extension build, or connector callback.
3. Compare token type, scopes, endpoint, method, content type, and Lucid-Api-Version with the exact current operation page.
4. For imports, inspect archive paths, document.json, IDs, product, size, and media references without uploading customer content.
5. For extensions, inspect manifest scopes, package versions, build output, developer mode, and browser console evidence.
6. Reproduce with the smallest sanitized fixture and one reversible action.
7. Record the proven cause, fix, verification, rollback, and evidence gaps.

Approval Boundaries

Do not broaden scopes, rotate credentials, alter sharing, upload documents, replay callbacks, or publish packages without owner approval.

Output

Return symptom, layer, evidence, ruled-out causes, confirmed cause, bounded fix, verification, rollback, and owner actions.

Error Handling

Governed Lucid Standard Import

Overview

Transform an approved diagram specification into a deterministic .lucid archive, create the document, verify it, and retain rollback evidence.

Prerequisites

• An approved diagram specification with data classification and owner
• A destination product and folder
• An authorized API key or OAuth user token with the exact create-document scope

Tool Discipline

Use Read, Glob, and Grep to inspect specifications and fixtures, WebFetch for current Standard Import and operation contracts, and Write or Edit for the local archive source and receipt only.

Current Contract

• A Standard Import file is a ZIP with required document.json, at least one page, and unique item IDs.
• Creation uses the documented multipart endpoint with file, product, and optional title or parent.
• The format evolves, so a previously valid archive may render differently later.

Authentication

Use Bearer authorization with an approved API key or OAuth user token accepted by the operation. Never print the token. Validate token type, scope, destination access, and current document API version before mutation.

Instructions

1. Freeze the input specification, intended product, folder, title, ownership, and rollback plan.
2. Build document.json and any /data or /images assets with unique stable IDs and safe relative paths.
3. Validate JSON, ZIP structure, uncompressed sizes, media types, referential integrity, and deterministic ordering locally.
4. Present a mutation preview including document count, pages, shapes, lines, data rows, images, and destination.
5. After approval, submit one idempotency-controlled creation request using exact documented headers and multipart fields.
6. Capture the returned identity without tokens, then retrieve or export only as permitted to verify representative content.
7. Record source digest, created ID, owner, verification, cleanup or retention decision, and rendering variance.

Approval Boundaries

Do not upload restricted source data, overwrite an existing document, guess a folder, or create duplicates after an ambiguous timeout.

Output

Return source digest, archive validation, mutation preview, created document ID, verification, rendering variance, owner, and rollback or cleanup.

Error Handling

Governed Lucid Data Import and Sync

Overview

Design an editor extension, and only when required a data connector, that imports or synchronizes approved data without inventing REST endpoints.

Prerequisites

• A classified source schema, stable record identifiers, and named data owner
• A Lucid developer application and explicit extension scopes
• A reconciliation, deletion, and rollback policy

Tool Discipline

Use Read, Glob, and Grep to inspect extension code and schemas, WebFetch for current Lucid contracts, and Write or Edit only for local implementation and evidence.

Current Contract

Lucid documents support data through the Extension API. Data connectors are an optional server-side companion for sources that require OAuth, scheduled updates, or webhook-driven refresh. Consult installed SDK types and official docs rather than guessing namespaces or methods.

Authentication

Keep source-system credentials server-side. Request the least Lucid extension scopes and OAuth access required. Never place API keys, refresh tokens, or client secrets in extension bundles, logs, fixtures, or document data.

Instructions

1. Classify the job as one-time import, user-triggered refresh, scheduled sync, or webhook-assisted connector sync.
2. Map source keys, field types, null handling, redaction, row ownership, and conflict policy before writing code.
3. Inspect the installed lucid-extension-sdk types and current data-import documentation.
4. Implement a deterministic transform with stable IDs and explicit validation errors.
5. Test against synthetic fixtures, including duplicate, deleted, reordered, and malformed records.
6. Present the intended scopes, data movement, write count, destination, and rollback before live access.
7. After approval, run a bounded canary and reconcile source, Lucid data, visual bindings, and deletions.
8. Record fixture digest, scope set, counts, rejects, drift, and rollback result.

Approval Boundaries

Do not read production data, register OAuth credentials, publish an extension, or enable scheduled/webhook sync without the responsible owners' approval.

Output

Return architecture choice, schema map, scopes, fixture results, mutation preview, canary reconciliation, rejects, and rollback evidence.

Error Handling

Lucid Cost and Value Review

Overview

Produce an evidence-backed right-sizing plan for licenses, seats, plan-dependent capabilities, and integration operations. Lucid's public developer documentation does not establish a universal per-export or per-API-call price.

Prerequisites

• Authorized seat, role, plan, renewal, and usage evidence
• Current contract or official pricing source supplied by the account owner
• Named business and data owners for affected integrations

Tool Discipline

Use Read, Glob, and Grep for approved exports and repository evidence, WebFetch for current official plan documentation, and Write or Edit only for local analysis and a proposed action ledger.

Current Contract

Separate verified commercial terms from technical limits and internal operating costs. Treat public list prices and plan features as time-sensitive; never extrapolate them from API traffic, archive size, or export count.

Authentication

Prefer redacted offline exports. If account access is required, use read-only least privilege and never expose invoices, tokens, personal data, or contract terms beyond the approved audience.

Instructions

1. Record evidence date, billing period, currency, contract source, current plan, and exclusions.
2. Inventory assigned seats, roles, active owners, dormant accounts, shared integrations, extensions, connectors, and critical documents.
3. Attribute cost only from invoices or current official commercial evidence; mark unknowns explicitly.
4. Measure operational effort separately: support, failures, connector hosting, observability, and manual reconciliation.
5. Propose reversible actions with owner, dependency, savings hypothesis, risk, and restoration path.
6. Present removals, role changes, plan changes, and integration shutdowns for approval.
7. After approved changes, compare realized invoices and service outcomes over a complete billing period.

Approval Boundaries

Do not remove seats, downgrade plans, cancel services, or disable integrations based only on inactivity signals or estimated pricing.

Output

Return evidence dates, verified and unknown costs, seat/role inventory, value signals, proposals, risks, approvals, and follow-up measurement dates.

Error Handling

Example

Redacted Lucid Debug Bundle

Overview

Create a minimal evidence package that reproduces a Lucid failure while excluding credentials, sensitive document content, and unnecessary personal data.

Prerequisites

• Incident identifier, time window, affected component, and expected behavior
• Approval to inspect relevant local artifacts and sanitized responses
• A clean output directory outside application source and secret stores

Tool Discipline

Use Read, Glob, and Grep to collect bounded evidence, WebFetch for current contract comparison, and Write or Edit only inside the declared bundle directory.

Current Contract

Useful evidence differs by surface: REST requests need method, path family, safe headers, status and request identifiers; Standard Import needs archive structure and sanitized samples; extensions/connectors need versions, manifests, build output, and minimal fixtures.

Authentication

Never copy Authorization, cookies, API keys, OAuth codes, refresh tokens, client secrets, signed URLs, or raw environment files. Replace sensitive identifiers consistently so relationships remain diagnosable.

Instructions

1. Declare incident scope, bundle path, retention, recipients, and exclusion rules.
2. Inventory candidate files and reject caches, dependencies, binaries, full documents, and unrelated logs by default.
3. Capture tool and SDK versions, safe manifest fields, operation category, sanitized request/response metadata, and exact timestamps.
4. For imports, include a structurally equivalent minimal archive or manifest—not protected production content.
5. For extension/connector failures, add a synthetic fixture and the smallest failing build/test receipt.
6. Scan recursively for token patterns, credentials, emails, personal data, and document content; manually review hits.
7. Write a manifest with file digests, provenance, redactions, reproduction steps, expected/actual behavior, and gaps.
8. Obtain approval before transmitting; record destination and deletion date.

Approval Boundaries

Do not collect from production, contact Lucid support, or transmit the bundle without incident and data-owner authorization.

Output

Return bundle path, manifest digest, files included/excluded, redaction results, reproduction status, evidence gaps, and sharing approval.

Error Handling

Governed Lucid Integration Deployment

Overview

Move a Lucid extension and any companion data connector through reproducible build, canary, publication, and rollback gates using current official tooling.

Prerequisites

• A clean reviewed revision with passing local build, type, manifest, fixture, and secret scans
• Environment owners, approved scopes, release notes, canary users, and rollback artifact
• Current lucid-package and project-specific connector deployment instructions

Tool Discipline

Use Read, Glob, and Grep for repository and release evidence, WebFetch for current Lucid publication contracts, and Write or Edit only for local manifests, receipts, and release notes.

Current Contract

Lucid editor extensions use the official package CLI and Extension SDK. A data connector is a separately operated server component with its own identity, hosting, secrets, observability, and rollback. Verify installed CLI syntax rather than relying on cached commands.

Authentication

Separate developer, publisher, connector-runtime, and source-system identities. Keep credentials in approved secret stores; use least privilege and ensure rollback does not depend on an expired personal token.

Instructions

1. Pin source revision, CLI/SDK versions, manifest, scopes, connector image, fixtures, and documentation.
2. Run the repository's secretless build, type, manifest, fixture, and compatibility gates.
3. Produce immutable extension and connector artifacts with checksums and provenance.
4. Compare requested scopes, OAuth redirects, data flows, and webhook behavior with the reviewed release.
5. Present artifact digests, target, canary cohort, expected mutations, monitoring, and rollback commands for approval.
6. After approval, upload or deploy only to the documented staging/developer target and run the canary.
7. Reconcile UI behavior, connector data, permissions, errors, and service health before production publication.
8. Require a second approval for production publication or traffic change; retain the prior artifact until the rollback window closes.

Approval Boundaries

Never publish, change OAuth settings, expose a connector, rotate production secrets, or promote traffic implicitly.

Output

Return source revision, artifact digests, version evidence, scopes, approvals, canary results, publication receipt, monitoring, and rollback status.

Error Handling

Minimal Lucid Standard Import Smoke Test

Overview

Create the smallest deterministic .lucid fixture, validate it offline, and optionally upload exactly one disposable Lucidchart document after approval.

Prerequisites

• A clean output directory and current Standard Import documentation
• For live mode, an approved API key or OAuth user token, product, destination, and cleanup owner
• No production or sensitive data

Tool Discipline

Use Read, Glob, and Grep to inspect local examples, WebFetch for the current import and operation contract, and Write or Edit only for the fixture and redacted receipt.

Current Contract

A .lucid Standard Import file is a ZIP containing document.json. It needs at least one page and unique item IDs. Product selection distinguishes Lucidchart from Lucidspark.

Authentication

Offline validation needs no credential. Live creation uses approved Bearer authorization and any required current version header. Never persist or echo the token.

Instructions

1. Re-fetch the Standard Import overview and exact create-document operation before coding.
2. Write a deterministic document.json with one Lucidchart page, one simple shape, stable unique IDs, and no external assets.
3. Package it as a ZIP with document.json at the archive root; record its SHA-256 digest.
4. Validate JSON, members, paths, compression, IDs, product, page count, and uncompressed size offline.
5. Default to stopping here and report the reusable fixture.
6. For live mode, present destination, title, one-document mutation, credential class, verification, and deletion plan.
7. After approval, create once, capture the redacted ID, verify representative content, and delete only if cleanup was approved.

Approval Boundaries

Do not upload automatically, reuse an ambiguous request, write to a guessed folder, or use real customer data in a hello-world fixture.

Output

Return mode, fixture path, digest, structural checks, planned or created document ID, verification, and cleanup status.

Error Handling

Example

mode=offline; product=lucidchart; pages=1; shapes=1; archive-sha256=...; live-mutations=0

Resources

…

Lucid Installation and Authentication

Overview

Select the least-privilege credential class for the operation, configure a secretless local contract, and verify identity and scope without exposing credentials.

Prerequisites

• The exact Lucid operation, resource owner, environment, and required scopes
• A registered OAuth application when user or account OAuth is selected
• An approved secret store and rotation owner

Tool Discipline

Use Read, Glob, and Grep to inspect configuration templates, WebFetch for current auth and scope contracts, and Write or Edit only for secretless examples or redacted receipts.

Current Contract

Lucid documents API keys, OAuth user tokens, and OAuth account tokens. OAuth applications use Authorization Code Flow. REST credentials are normally sent as Authorization: Bearer ...; an operation may also require a resource-specific Lucid-Api-Version header.

Authentication

• Use an API key only where the current operation supports it and personal ownership is acceptable.
• Use OAuth user tokens for delegated user access and consented scopes.
• Use OAuth account tokens only for documented account-level use with administrator authorization.
• Never substitute a fabricated Lucid-Api-Key header or log authorization values.

Instructions

1. Re-fetch authentication methods, the exact operation, access scopes, and headers.
2. Create an auth decision record: credential class, principal, resources, scopes, expiration, rotation, and revocation.
3. Inspect the project for hard-coded tokens, unsafe redirects, committed environment files, and mixed credential classes.
4. Define environment-variable names and a secret-provider interface without writing values.
5. For OAuth, validate exact redirect URIs, state handling, authorization-code exchange, secure token storage, refresh behavior, and revocation.
6. Present any app registration, consent, account grant, or secret creation for explicit approval.
7. After credentials are provisioned outside the transcript, perform the smallest documented read-only verification and capture only status, principal class, scopes, and safe request identifiers.

Approval Boundaries

Do not create keys, register or modify OAuth apps, authorize accounts, broaden scopes, or rotate/revoke credentials without the relevant owner.

Output

Return auth decision, required scopes and headers, secretless configuration, verification receipt, rotation/revocation owner, and unresolved access gaps.

Error Handling

Lucid Local Development Loop

Overview

Establish a repeatable edit-build-test loop for an existing Lucid extension or connector, grounded in the installed project and official lucid-package tooling.

Prerequisites

• A local project with lockfile, manifest, and documented runtime versions
• Synthetic fixtures and no production credentials by default
• A disposable Lucid developer test target when UI verification is needed

Tool Discipline

Use Read, Glob, and Grep to inspect the project, WebFetch for official CLI/SDK guidance, and Write or Edit only for scoped source, fixture, test, or local documentation changes.

Current Contract

Lucid maintains lucid-package and lucid-extension-sdk. Project scripts and installed CLI --help define the exact runnable commands; official guidance warns against guessing SDK types or pnpm argument syntax.

Authentication

Keep the default loop offline and fixture-driven. Developer-mode access uses a dedicated least-privilege identity; connector/source secrets remain in an approved local secret provider and never enter bundles or snapshots.

Instructions

1. Read repository instructions, manifest, package manager, lockfile, scripts, SDK versions, and test configuration.
2. Query installed command help and compare it with current official CLI and SDK documentation.
3. Select the narrowest loop: type/build, manifest validation, unit fixture, connector contract, or editor smoke test.
4. Run the existing deterministic command before editing and preserve its receipt.
5. Make one bounded change, rerun the narrow check, then run all affected local gates.
6. For developer-mode testing, preview scopes, bundle identity, test document, and expected mutations before installation.
7. Record command, duration, changed files, fixture digest, expected/actual result, and cleanup.

Approval Boundaries

Do not add dependencies, install into a Lucid account, contact a live source, or change registered application settings without approval.

Output

Return environment/version evidence, selected loop, commands, test receipts, changed files, developer-mode actions, cleanup, and remaining drift.

Error Handling

Example

Evidence-Driven Lucid Performance Tuning

Overview

Tune one measured workflow at a time while preserving document fidelity, data reconciliation, authorization, and documented limits.

Prerequisites

• A reproducible scenario, representative sanitized fixture, baseline, and service objective
• Component classification: import, export, REST operation, editor extension, or connector
• Owners for data correctness and any live environment

Tool Discipline

Use Read, Glob, and Grep for code, fixtures, and receipts, WebFetch for current limits/contracts, and Write or Edit only for local benchmarks, scoped improvements, and reports.

Current Contract

Each Lucid surface has different constraints. Standard Import performance depends on archive structure, uncompressed assets, pages, objects, and data; extension/connector performance depends on the installed SDK, transforms, network behavior, and UI work. Rate limits are endpoint-specific.

Authentication

Benchmark offline first. Use dedicated test credentials and synthetic data for live measurements. Never log tokens or expose restricted document data in traces.

Instructions

1. Define the user-visible objective and correctness invariants before measuring.
2. Record versions, fixture digest, cold/warm state, network assumptions, concurrency, and timing method.
3. Establish at least three comparable baseline samples with latency distribution and resource counts.
4. Profile the dominant phase: archive generation/upload/render, export polling/download, extension transform/UI, or connector fetch/reconcile.
5. Propose one reversible change such as bounded batching, deduplication, incremental reconciliation, asset reduction, caching with invalidation, or deferred UI work.
6. Run the same samples and compare latency, memory, requests, payload, rejects, document fidelity, and reconciliation.
7. Present any live load increase or concurrency change for approval; honor endpoint-specific limits and backpressure.
8. Keep only improvements that meet both performance and correctness thresholds.

Approval Boundaries

Do not load-test Lucid or a source system, increase concurrency, reduce validation, or alter production documents without approval.

Output

Return scenario, versions, baseline and candidate distributions, bottleneck evidence, correctness checks, limits consulted, decision, and rollback.

Error Handling

Lucid Production Readiness Gate

Overview

Prove a Lucid integration is supportable, secure, reversible, and contract-grounded before authorizing production use.

Prerequisites

• Immutable release revision and artifacts with provenance
• Named service, data, security, and rollback owners
• Current architecture, data classification, scope matrix, runbook, and service objectives

Tool Discipline

Use Read, Glob, and Grep to verify repository evidence, WebFetch for current Lucid contracts and status, and Write or Edit only for the local gate receipt and approved documentation fixes.

Current Contract

Readiness must match the actual surface: REST credential and version headers, Standard Import constraints, Extension API scopes and bundle behavior, and connector hosting/OAuth/webhook responsibilities. A generic green checklist is insufficient.

Authentication

Verify principal type, least scopes, secret-store location, owner, rotation, revocation, redirect URIs, and break-glass procedure without exposing values.

Instructions

1. Pin revision, artifacts, dependencies, SDK/CLI versions, manifests, fixtures, and target environment.
2. Re-fetch exact official pages for authentication, scopes, headers, limits, and the chosen integration surface.
3. Verify build, type, manifest, schema, secret, dependency, fixture, migration, and rollback gates from clean state.
4. Exercise happy path, invalid input, insufficient scope, throttling, partial failure, ambiguous response, upstream outage, and rollback.
5. Reconcile data lineage, retention, deletion, ownership, document destinations, and connector/webhook behavior.
6. Verify logs are redacted; alerts, dashboards, status dependency, on-call, escalation bundle, and runbook are usable.
7. Record every control as PASS, FAIL, or NOT APPLICABLE with evidence; unresolved critical controls fail closed.
8. Present blast radius, canary, monitoring, publication/deployment actions, and rollback for explicit production approval.

Approval Boundaries

This skill reports readiness; it never treats a checklist completion as authorization to publish, deploy, rotate credentials, or mutate production.

Output

Return release identity, gate matrix, official evidence date, test receipts, risks, owners, approval state, canary plan, and rollback evidence.

Error Handling

Lucid Rate-Limit and Backpressure Design

Overview

Ground request control in the exact Lucid endpoint contract and observed responses. There is no justified pack-wide fixed requests-per-minute value.

Prerequisites

• Inventory of operations, mutation semantics, concurrency, callers, and service objectives
• Current endpoint documentation and sanitized response headers/bodies
• Stable idempotency or reconciliation strategy for mutations

Tool Discipline

Use Read, Glob, and Grep to inspect clients and tests, WebFetch for current endpoint/limit documentation, and Write or Edit only for local policy, code, tests, and receipts.

Current Contract

Treat limits as endpoint/API-specific and time-sensitive. A legacy or Data API limit must not be generalized to document, export, import, Extension API, or connector operations. Server responses and current endpoint pages control.

Authentication

Rate limiting does not justify credential pooling or scope expansion. Partition traffic by approved principal and tenant while keeping tokens out of metrics and logs.

Instructions

1. Enumerate each operation's method, read/write effect, caller, principal, concurrency, and retry safety.
2. Re-fetch the exact operation and rate-limit documentation; record only explicitly documented values.
3. Instrument requests, success/error counts, latency, queue age, and safe server rate-limit/retry metadata.
4. Use bounded queues, per-operation concurrency, jitter, and backpressure before retries.
5. Retry only documented transient failures. For writes, require idempotency support or reconciliation before replay.
6. Honor documented Retry-After or equivalent server guidance when present; otherwise use conservative capped backoff based on observed behavior.
7. Test synthetic 429, timeout-before-response, partial batch, queue saturation, cancellation, and recovery.
8. Present any production concurrency or replay-policy change for approval and deploy as a monitored canary.

Approval Boundaries

Do not increase production load, pool credentials, bypass queues, or replay ambiguous mutations without approval and reconciliation.

Output

Return operation matrix, documented/unknown limits, observed response evidence, queue/retry policy, tests, approval, canary result, and remaining risks.

Error Handling

Lucid Integration Reference Architecture

Overview

Select the smallest supported Lucid surface for the requirement and document trust, data, failure, and ownership boundaries before implementation.

Prerequisites

• Functional requirements, data classification, users, service objectives, and failure tolerance
• Known Lucid product, ownership model, and plan/account constraints
• Current official contracts for candidate surfaces

Tool Discipline

Use Read, Glob, and Grep to inspect the system and constraints, WebFetch for current Lucid contracts, and Write or Edit only for architecture records and diagrams in the approved project.

Current Contract

• Use REST operations for documented server-side document/account workflows.
• Use Standard Import for deterministic file-driven document creation.
• Use an editor extension for in-editor UI, document content, and document data behavior.
• Add a data connector only when server-side source authentication, scheduled refresh, or documented connector webhook behavior is required.

Authentication

Map each boundary to a principal: human/API key, OAuth user, OAuth account, extension, connector runtime, and upstream source. Define scopes, secret storage, rotation, revocation, consent, and audit evidence.

Instructions

1. Capture actors, use cases, latency, volume, data classes, residency, ownership, and recovery objectives.
2. Re-fetch the candidate surface documentation; reject capabilities supported only by memory or third-party examples.
3. Draw component, trust-boundary, data-flow, and failure/recovery views.
4. For every edge, specify schema, identity, authorization, validation, retry/idempotency, retention, and observability.
5. Compare at least two viable options on complexity, supportability, least privilege, failure isolation, and reversibility.
6. Explicitly exclude unsupported generic document webhooks, document locking, universal quotas, and unverified cost assumptions.
7. Define canary, reconciliation, disaster recovery, ownership, and decommissioning.
8. Record the decision, evidence date, alternatives, assumptions, approval boundaries, and review trigger.

Approval Boundaries

Do not register applications, provision hosting, move data, publish extensions, or commit to commercial terms during architecture design.

Output

Return chosen surfaces, diagrams, principal/scope matrix, data contracts, failure model, options, decision, assumptions, owners, and approval gates.

Error Handling

Lucid SDK Implementation Patterns

Overview

Implement an editor-extension feature from the installed SDK, project manifest, and official guidance—never from guessed type names or stale snippets.

Prerequisites

• Existing extension project with lockfile, manifest, scripts, and pinned versions
• Defined user behavior, document/data boundary, scopes, and test fixture
• Current official Extension API and package CLI references

Tool Discipline

Use Read, Glob, and Grep to inspect source, installed declarations, manifests, and tests; use WebFetch for current official docs; use Write or Edit only for bounded local changes and evidence.

Current Contract

lucid-package supplies project tooling and lucid-extension-sdk supplies supported APIs and types. Official Lucid AI guidance says to consult documentation and types, avoid guessing APIs, use correct pnpm mode syntax, and request least extension scopes.

Authentication

Editor bundles must not contain server secrets. Put source OAuth and confidential credentials behind an approved connector/server boundary. Review manifest scopes before any developer install.

Instructions

1. Read repository instructions, package manifest, Lucid manifest, lockfile, scripts, and relevant tests.
2. Inspect installed SDK declaration/source files for the exact API, callback, return, error, and availability contract.
3. Re-fetch the corresponding official topic and note version/documentation drift.
4. Design a thin typed boundary that validates external data and converts errors into explicit user-safe states.
5. Implement the smallest feature using existing project patterns; avoid global mutable state and undocumented object shapes.
6. Add tests for success, invalid input, unavailable context, insufficient scope, cancellation, and partial failure.
7. Run project type/build/manifest/test commands using installed --help and correct package-manager argument passing.
8. Present dependency, scope, or developer-install changes for approval and record exact receipts.

Approval Boundaries

Do not upgrade dependencies, broaden scopes, install developer packages, connect production data, or publish without approval.

Output

Return SDK/CLI versions, inspected types/docs, chosen pattern, changed files, scopes, gate receipts, drift, and approval state.

Error Handling

Lucid Integration Security Baseline

Overview

Establish least privilege, safe data handling, trustworthy package boundaries, and auditable operations for the exact Lucid integration surface.

Prerequisites

• Architecture and data-flow inventory with classifications and owners
• Credential/principal and extension-scope inventory
• Repository, artifact, deployment, logging, retention, and incident evidence

Tool Discipline

Use Read, Glob, and Grep for bounded static inspection, WebFetch for current Lucid security contracts, and Write or Edit only for approved local remediation and redacted reports.

Current Contract

Lucid exposes multiple credential classes, operation-specific scopes/headers, Standard Import archives, editor-extension scopes, and optional connector runtimes. Each creates distinct trust boundaries; an extension bundle is not a safe place for confidential credentials.

Authentication

Map API keys and OAuth user/account tokens to an owner, exact scopes/resources, storage, expiration, rotation, revocation, and audit trail. Validate OAuth redirect URIs and state. Never log tokens, authorization codes, refresh tokens, cookies, or signed URLs.

Instructions

1. Pin the reviewed revision and enumerate actors, components, data stores, network edges, documents, and source systems.
2. Re-fetch authentication, scope, header, and surface-specific official docs.
3. Search tracked files and build artifacts for credentials, unsafe environment files, overly broad scopes, sensitive fixtures, and unredacted logs.
4. Threat-model credential theft, malicious imports, archive traversal/expansion, injected source data, cross-account access, connector compromise, replay, and supply-chain drift.
5. Validate inputs, archive paths/sizes/types, stable IDs, outputs, redirects, state, authorization, tenant boundaries, and redaction.
6. Verify pinned dependencies, reproducible builds, artifact provenance, change review, secretless CI, and rollback.
7. Rank findings by exploitability and impact; propose reversible fixes with owners and evidence.
8. Present credential, scope, retention, or production changes for explicit approval and verify remediation independently.

Approval Boundaries

Do not inspect secret values, rotate/revoke credentials, alter scopes, delete data, change retention, or publish security-sensitive changes without authorization.

Output

Return surfaces, trust boundaries, principal/scope matrix, findings with evidence, severity, remediation, approvals, verification, and residual risk.

Error Handling

Reversible Lucid Upgrade and Migration

Overview

Move one Lucid contract boundary at a time with an immutable baseline, representative fixtures, canary evidence, and tested rollback.

Prerequisites

• Clean source revision, dependency lockfile, manifests, deployed artifact identity, and current production version
• Representative synthetic imports, documents, data, and connector events where applicable
• Owners for code, data, Lucid application, source system, and rollback

Tool Discipline

Use Read, Glob, and Grep for version and usage inventory, WebFetch for current official migration contracts, and Write or Edit only for approved local changes, tests, and receipts.

Current Contract

The Standard Import format evolves and may render differently over time. Extension SDK/CLI and manifest behavior are versioned through project dependencies. REST resources may require Lucid-Api-Version. These are separate migration axes and must not be changed blindly together.

Authentication

Preserve credential classes and least scopes unless a documented target contract requires change. Treat new scopes, redirect URIs, consent, account grants, and secret rotation as separate approved migrations.

Instructions

1. Inventory current and target package/CLI versions, API-version headers, manifests/scopes, import fixtures, connector schemas, and deployment artifacts.
2. Capture a clean baseline: build, types, manifests, tests, fixture imports/exports, data reconciliation, and rollback.
3. Re-fetch exact official docs and inspect target installed types/changelogs; create a breaking-change matrix.
4. Split changes into reversible steps: tooling/dependencies, compile fixes, manifest/scopes, format/schema, API version, and deployment.
5. Present dependency edits and any auth/data contract changes for approval.
6. Apply one step, regenerate the lockfile with the project package manager, and run narrow then full affected gates.
7. Test old/new representative fixtures and compare rendering, data, identifiers, errors, and performance.
8. Deploy a bounded canary after approval; reconcile, monitor, and roll back on threshold breach before broader promotion.

Approval Boundaries

Do not upgrade packages, change API versions/scopes, rewrite stored data, reinstall extensions, or deploy merely because a newer version exists.

Output

Return baseline/target matrix, official evidence, changed files, dependency and scope diffs, tests, canary, rendering/data variance, approval, and rollback status.

Error Handling

Lucid Data-Connector Webhook Lifecycle

Overview

Build webhook-assisted data synchronization only within Lucid's documented data-connector model. Do not claim generic Lucid document, shape, or collaboration event webhooks.

Prerequisites

• A justified Lucid data connector and supported source-system webhook contract
• Stable source record/event identifiers and reconciliation API
• Endpoint, identity, retention, observability, replay, and rollback owners

Tool Discipline

Use Read, Glob, and Grep to inspect connector and handler code, WebFetch for current Lucid and source contracts, and Write or Edit only for local implementation, synthetic fixtures, and redacted receipts.

Current Contract

Lucid documents a webhook SDK in the context of data connectors. Exact interfaces come from the current SDK/docs. Delivery authentication, signing, event names, ordering, retry, and retention may be source-system responsibilities and must be verified there—not invented as universal Lucid guarantees.

Authentication

Authenticate each boundary independently: Lucid connector, webhook source, and upstream reconciliation API. Keep secrets server-side; validate the source's documented authenticity mechanism and never invent a LUCID_WEBHOOK_SECRET convention.

Instructions

1. Prove the use case belongs to a data connector and identify the authoritative source system.
2. Re-fetch Lucid webhook/connector docs and the source's official delivery contract; record unknown guarantees.
3. Define event envelope validation, stable IDs, freshness/replay window, deduplication, ordering tolerance, and reconciliation.
4. Make the receiver acknowledge quickly and enqueue bounded work; isolate poison events and apply backpressure.
5. Treat webhook data as a change hint. Fetch/reconcile authoritative state before mutating connector data when the source contract permits.
6. Test valid, invalid-auth, malformed, duplicate, reordered, delayed, missing-record, partial-sync, and replay scenarios with synthetic fixtures.
7. Present registration, endpoint exposure, secrets, expected traffic, data mutations, and disable/rollback plan for approval.
8. After approval, enable a bounded canary and record registration ID, counts, rejects, duplicates, lag, reconciliation, and rollback.

Approval Boundaries

Do not expose/register endpoints, create secrets, replay production events, mutate connector data, or enable delivery without approval.

Output

Return contract evidence, architecture, auth method, validation/dedup policy, tests, mutation preview, canary receipt, reconciliation, and rollback.

Error Handling