Skip to content

X provider and credential boundary

Status: Slice 2 implemented as a non-destructive provider boundary. Live X mutation remains disabled.

Ownership

The credential-owning implementation is the feed-independent ancientos_x_provider package in the x-feed-worker repository. Physical placement lets the existing deployment retain sole access to its owner-only .env; the package is not feed-domain logic. AncientOS's app.integrations.x_provider contract accepts only the package's immutable provider snapshot, never its OAuth signer or raw environment.

The public snapshot allowlists provider name, authorization profile ID, configured expected account, verified authenticated identity, auth mechanism, capability authorization, readiness booleans, and fixed failure reasons. It contains no credential values, headers, sessions, response bodies, or reusable client material. Luna, prompts, LifeVault, Zeus, and routine logs may receive only this safe snapshot or a further reduction of it.

OAuth and identity

OAuth1 user context is the v1 path. X Developer Console confirms the existing app and @ngreene token are Read and write. The boundary constructs its OAuth1 signer privately and permits only the read-only GET /2/users/me operation in this slice. The returned user ID must exactly match configured user ID 15058774; when a configured username is present, its normalized value must also match. Mismatch withholds authenticated identity and fails closed. A caller cannot supply a target account through an LLM-facing request.

OAuth2 remains exclusively owned by the existing bookmark worker. The new boundary reads only the four OAuth1 variables and does not read, return, refresh, or persist OAuth2 tokens. If a later design shares OAuth2, it must first replace the current refresh path with one locked, atomic, generation-safe single writer. No second refresh writer is permitted.

Readiness and disabled operations

Readiness distinguishes authentication, verified identity, OAuth1 authorization, billing, and mutation enablement. The current expected state is OAuth1 authorization ready, billing unverified, and mutation disabled. Billing uncertainty blocks future execution rather than provider-boundary implementation.

The safe capability list may report authorization readiness for delete post, delete reply, remove like, and undo repost, but every mutation implementation is disabled. The package exports no mutation method and makes no destructive X request. Later inventory and execution slices must add their own separately authorized contracts and retain Lich, Zeus, identity, billing, rate, and exact target gates.