동료가 에이전트와 함께 만들어준 크리틱

[spilist]

Ceal Architecture Critique

Executive verdict

Ceal addresses a real operational problem: an AI agent needs to act through a
provider such as Slack without receiving a broad provider credential, guessing
provider object identifiers, duplicating an uncertain write, or treating a
successful process exit as proof of provider state. Ceal's current interface
addresses that problem with policy-filtered operation discovery, opaque target
references, Gateway-side validation and execution, per-capability idempotency
policy, and receipt/readback evidence
(Ceal capability contract,
write contract,
unknown-outcome handling).

The critical finding is that most of the underlying security and reliability
problems have mature models or candidate mechanisms: RBAC and ABAC cover role-
and attribute-based policy
(NIST RBAC,
NIST SP 800-162); OAuth Rich
Authorization Requests carries fine-grained authorization data, and OAuth Token
Exchange defines a protocol for exchanging delegated or impersonated credentials
(RFC 9396,
RFC 8693); OpenAPI describes API
operations (OpenAPI 3.2.0);
and HTTP defines safety, idempotency, and retry constraints
(RFC 9110 §9.2). Ceal
should reuse or align with these mechanisms where their semantics match, and
reserve Ceal-specific design for the agent control loop: translating
natural-language requests into policy-permitted structured actions, treating
tool metadata as untrusted data, controlling the agent's retries, representing
delegated actors, and limiting the agent's completion claims to what the
evidence establishes.

The recommended product boundary is therefore:

Ceal should be an agent-safe projection and orchestration layer that reuses or
aligns with established identity, authorization, API-contract, credential,
and distributed-systems mechanisms where their semantics match.

Scope

This report evaluates the ceal-cli interface. The canonical protocol and
operator implementation are owned outside this repository, so this report
treats concerns about underlying Gateway mechanisms as interface risks rather
than implementation findings
(repository ownership).

Example used below: post an approved incident update to an authorized Slack
channel, then verify the result without exposing a Slack credential to the
agent.

Assessment matrix

Ceal surface	Mature foundation	Assessment	Recommended treatment
Profile, Membership, Session	RBAC defines users, roles, permissions, operations, objects, role hierarchies, and constraints; ABAC evaluates subject, object, operation, and environment attributes against policy (NIST RBAC, NIST SP 800-162).	A Profile can be a useful agent-facing authorization context, but it risks combining role, tenant, environment, provider account, and connector scope into one opaque concept. The Ceal handshake exposes Profile and Membership as distinct references but does not expose their policy semantics (handshake types).	Keep Profile as a projection. Define how it derives from principal, role or relationship assignments, attributes, tenant, and resource scope. Do not make Profile a second policy language.
Capability	RBAC permissions associate operations with objects. OAuth Rich Authorization Requests can carry structured authorization details, but each protected API defines their semantics (NIST RBAC, RFC 9396).	Ceal discovery describes an operation with an ID, effect, target requirement, input contract, and evidence requirement, while target access carries a separate grant reference and revision (discovery types, target grants). Possessing a capability_id is therefore not sufficient authority.	Define Capability as a policy-filtered operation contract, not a bearer capability. Map its action, resource, constraints, and grant to standard authorization concepts; use RAR only if its transport semantics fit the deployment.
Target Reference	Relationship-based systems such as Zanzibar model authorization over digital objects. OAuth Resource Indicators instead identify the service or resource server where a token will be used (Zanzibar paper, RFC 8707).	Ceal returns bounded opaque target references and directs agents not to substitute guessed or raw provider identifiers; access and capability-specific grants are evaluated separately from the reference (target-selection guidance, target grants).	Keep the opaque resource handle and bind it to Profile, operation, and grant context. Do not map an individual target object directly to an OAuth Resource Indicator; use that mechanism only for service/API audience restriction where applicable.
Gateway and provider Adapter	Zero-trust architecture authorizes access to resources rather than trusting network location. OAuth Token Exchange is a possible mechanism for delegated, impersonated, or narrower downstream credentials, but it does not define the deployment trust model (NIST SP 800-207, RFC 8693).	Keeping provider credentials behind a Gateway-controlled private execution boundary is sound, but it is an application of established least-privilege, proxy, policy-enforcement, and credential-broker patterns. Ceal says the Gateway authorizes Profile membership and connector scope before the private adapter executes (Gateway boundary).	Preserve this architecture. Treat Token Exchange as an optional implementation mechanism, not as evidence of the current Gateway design. Differentiate through the agent-safe contract and evidence model.
Discovery and input contract	OpenAPI provides a language-neutral description of HTTP API operations; JSON Schema describes and validates JSON structures (OpenAPI 3.2.0, JSON Schema Core).	Live, policy-filtered discovery is valuable for agents, but Ceal does not need to define a separate schema language for operation inputs and their validation rules. The TypeScript interface exposes input_contract as Record<string, unknown>; the decoder requires a ceal.* schema version and safe JSON but identifies no standard dialect (discovery types, input-contract decoder).	If adopting JSON Schema, fix the dialect and meta-schema URI and define a Ceal vocabulary for custom keywords and format assertion. If using OpenAPI, identify the exact Schema Object dialect rather than referring to OpenAPI generally. Derive the agent projection mechanically and keep agent-specific metadata as explicit extensions.
Client Session renewal	OAuth security guidance covers refresh-token resource binding, replay detection, rotation, revocation, and expiration; DPoP provides sender-constrained access and refresh tokens (RFC 9700 §4.14, RFC 9449).	Ceal uses custom /refresh and /revoke requests with Ceal-specific JSON schemas. The worker treats the refresh credential as a one-time rotation input, but the public interface does not identify an OAuth endpoint, grant, or token profile (session client, rotation handling).	Describe this as a custom Ceal bearer/refresh Session and compare its threat controls with RFC 9700. Call it an OAuth profile only if the implementation adopts and documents matching OAuth endpoint, grant, and token semantics. Consider sender-constrained, audience-restricted, short-lived credentials where deployment permits.
Replay Identity and write contract	HTTP distinguishes safe and idempotent methods and warns against automatically retrying a non-idempotent request without a way to know whether it was applied (RFC 9110 §9.2).	Ceal's protocol uses idempotency_key and declares whether idempotency is required, optional, or unnecessary. The guide separately mentions a stable idempotency value and a declared replay identity, without defining whether replay identity is the key alone or a wider tuple (write contract, leased call input, agent write guidance).	Define replay identity precisely: idempotency key, request reference, normalized mutation, lease/event identity, or a specified tuple. Use idempotency key alone only if the two concepts are proven equivalent.
Request Reference, Receipt, Readback	HTTP explicitly recognizes that a request may have been applied even when its response is lost and limits automatic retry accordingly (RFC 9110 §9.2.2).	Ceal associates that ambiguity with the original request reference and emits a receipt lookup instruction before repeating a possible write (unknown-outcome handling). The cited worker output documents this machine-readable recovery guidance, but it does not establish a system invariant that rejects an equivalent mutation from another caller or under a new idempotency key.	Keep the workflow and expose explicit terminal and nonterminal states. If replay prevention is a required security guarantee, enforce and test it at the host or Gateway rather than relying only on agent instructions.
Proof Level	Audit evidence can establish different facts: admission, authorization, execution, and provider-state verification are not equivalent. Ceal itself distinguishes a Gateway host_decision from nonclaims that provider execution or production audit was reached (handshake evidence); write receipts separately classify provider state and readback as unknown or verified (write receipt).	“Proof” can imply stronger assurance than a host decision provides. The underlying distinction is valuable, especially for agents that must decide what they may claim.	Prefer evidence level or verification state unless a level is backed by a defined verifier and integrity mechanism. Name concrete states such as gateway_authorized, provider_accepted, and provider_readback_verified.
Route Effect	HTTP treats safety and idempotency as separate, overlapping properties because they support different automation decisions: safe methods are idempotent, while some unsafe methods are also idempotent (RFC 9110 §9.2).	Ceal assigns remote_write both to a provider call and to discovery or receipt lookup that may only rotate a session credential (command definitions). The field conservatively combines provider and session mutation while omitting independent safety, idempotency, and retry properties.	Use orthogonal provider, session, and local effects; represent semantic safety and idempotency separately; and derive a conservative summary for simple guards.
Machine-readable recovery	Problem Details defines one standard extensible representation for machine-readable HTTP errors and identifiers for problem types and occurrences; it is not the only valid HTTP error representation (RFC 9457).	Ceal returns a structured error code, message, and optional next action (error shape).	Consider application/problem+json for Gateway HTTP errors or define an explicit mapping. Preserve Ceal error codes, recovery actions, and request/evidence correlation; keep transport-independent CLI recovery as a documented bounded extension.

Highest-priority design issues

1. Make the standards mapping part of the contract

The interface currently exposes Ceal nouns—Profile, Membership, Capability,
Grant, Target Reference, Session, and Proof Level—without a normative mapping
to standard IAM and protocol concepts. The result is ambiguity about which
concepts are projections and which are independent security mechanisms. For
example, discovery returns both a Capability identifier and a separate Grant
reference, while the handshake returns both Profile and Membership references
(protocol types).

Publish a machine-readable and prose definition such as:

Ceal term	Precise interpretation
Profile	Selected authorization context derived from principal assignments, attributes, tenant, and environment
Membership	Assignment or relationship connecting a principal to that context
Capability	Policy-filtered operation contract
Grant	Entitlement or policy-grant snapshot reference and revision for an operation-resource pair
Target Reference	Opaque resource handle, not bearer authority
Session	Custom Ceal client authentication state whose threat controls are declared explicitly and compared with applicable OAuth guidance
Receipt	Correlated operation-status and audit evidence
Proof Level	Evidence or verification state with an identified verifier

Do not treat a Grant reference or revision as an authorization decision. Model
the Grant snapshot separately from host_decision, auth_decision, and
policy_decision, because the protocol exposes these as distinct fields
(grant snapshot and decisions).

2. Split effect classification into independent dimensions

An approval system needs to distinguish “read Slack,” “post to Slack,” “rotate a
Gateway refresh token,” and “write a local cache.” The current Route Effect
cannot express those differences because it intentionally reports the widest
possible effect of a command
(Route Effect definition).

At minimum, define the following underlying dimensions:

Dimension	Example values
Provider effect	read or mutation
Session effect	none, renewal, or revocation
Local effect	none or mutation
Semantic safety	safe or unsafe
Idempotency semantics	idempotent or non-idempotent
Retry prerequisite	none, stable key, state readback, or prohibition

Approval and evidence policy can derive from these dimensions and the
Capability contract. The existing remote_write value can remain as a
mechanically derived warning when the provider effect is mutation or the
session effect is renewal or revocation.

3. Treat purpose as an assertion unless it is independently bound

The public call envelope carries purpose as a string
(call request).
The CLI generates a fixed sentence rather than accepting purpose text from its
command line
(CLI-generated purpose);
other protocol callers can populate the field.
The receipt carries purpose_sha256, which lets a verifier compare candidate
purpose text with the recorded digest. That field alone does not establish
authorship, approval, or semantic truth
(write receipt).
OAuth Token Exchange can represent the current actor and a nested history of
prior actors, but prior actors are informational and must not be used for access
control decisions
(RFC 8693 §4.1).

For security decisions, bind the asserted purpose to provenance whose identity,
integrity, and authority the deployment verifies—for example, a verified
approval record, user request, workflow event, lease, or signed task envelope.
Preserve subject, current actor, and prior-actor history as distinct
provenance. Enforce attenuation through current policy and top-level
authorization claims, not by
assuming the history chain grants or limits authority. Display unverified
purpose as an assertion, not as authorization evidence.

4. Define evidence by verifier and fact

The protocol's existing distinction between host_decision, unknown provider
state, and verified provider readback is stronger than a generic success flag
(Gateway evidence types, write receipt).
Make that distinction the model itself:

State	Claim it supports
request_validated	The request matched the accepted schema.
gateway_authorized	The Gateway allowed the action under a named policy/grant revision.
provider_dispatch_attempted	The Gateway or Adapter attempted to send the provider request; provider receipt is not established.
provider_response_received	A response was observed at the provider boundary; its application-level meaning is classified separately.
provider_operation_accepted	The provider explicitly accepted the operation under a defined synchronous or asynchronous contract; committed state is not implied.
provider_state_readback_verified	A subsequent provider read confirmed the expected object or state.
outcome_unknown	No completion or non-completion claim is justified.

Each state should identify the observation point, verifier, correlation
reference, integrity protection, and nonclaims. This makes the evidence useful
without calling every Gateway assertion “proof.”

Where Ceal should differentiate

Ceal's agent-specific value lies in controls at the boundary between
probabilistic planning and deterministic systems:

1. Untrusted discovery metadata. The agent guide already says catalog and
   help text are descriptive data, not higher-priority instructions
   (agent guide).
   This is an agent-specific interpretation rule: the agent must treat
   discovered descriptions as data that cannot override the caller's
   instructions or policy.

2. Natural-language intent resolution. The agent searches a bounded,
   policy-filtered target catalog and receives opaque references rather than
   inventing provider identifiers
   (capability discovery,
   target response types).
   Ceal can own the conversion from a user's request to an exact permitted
   action, target reference, and structured input.

3. Autonomous retry control. Ambiguous outcomes are a mature distributed-
   systems problem, but an agent can turn ambiguity into duplicate side effects
   without human intervention. Ceal documents a machine-readable recovery
   workflow: preserve the declared replay identity, inspect the original
   request's receipt, and do not invent another write
   (agent write guidance).
   This is guidance, not proof that the host or Gateway blocks an equivalent
   mutation submitted with a new identity.

4. Evidence-aware completion. An agent must translate machine evidence into
   a natural-language claim without upgrading “Gateway accepted” into “Slack now
   contains the message.” Ceal's explicit unknown and verified readback states
   provide a sound basis for that control
   (write receipt states).

Prioritized recommendations

1. Publish normative concept definitions and standards mappings. Mark every
   comparison as an exact mapping, compatible implementation option, analogy,
   extension, or intentionally independent mechanism.
2. Review the Session protocol against OAuth security guidance. Document
   token audience, sender constraint, rotation, replay response, revocation,
   expiry, and storage assumptions. Describe it as OAuth only if matching OAuth
   endpoint, grant, and token semantics are adopted.
3. Define Replay Identity before consolidating terminology. Specify whether
   it is an idempotency key, another identifier, or a tuple; use the established
   term only if the semantics are equivalent.
4. Split Route Effect into independent dimensions. Represent provider,
   session, and local effects separately; keep semantic safety, idempotency, and
   retry prerequisites on independent axes.
5. Qualify Capability and Proof Level, and define the input-contract dialect.
   Avoid implying bearer authority or cryptographic proof. Specify a fixed JSON
   Schema dialect, meta-schema URI, Ceal vocabulary, and format assertion
   policy—or the exact OpenAPI Schema Object dialect used.
6. Bind purpose to trusted provenance and make verification states
   normative. Preserve subject, actor, approval, and task identity separately;
   define the fact, verifier, integrity boundary, correlation reference, and
   nonclaims for each evidence state.

Conclusion

Ceal's strongest potential contribution is a disciplined agent execution loop:
resolve an exact permitted action, execute without exposing provider
credentials, direct the agent not to repeat an ambiguous write, and report only
what the evidence supports. Each prevention or standards-conformance claim
needs its own testable invariant.

[coderabbitai]

🔗 Related PRs

corca-ai/lighthouse#472 - chore(story-chain): finish sufficiency review compaction [merged]
corca-ai/moonlight#2064 - feat: add Amplitude experiment skill [open]
corca-ai/moonlight#2078 - feat: add Amplitude experiment platform [open]
corca-ai/moonlight#2081 - feat: add Amplitude experiment platform [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[spilist]

Follow-up decision: bounded concurrency and deferred capability execution

After reviewing this issue against the current Worker and Gateway trees, we made one product decision that should be coordinated across the repositories:

A ceal call is allowed to answer successfully with a nonterminal pending state instead of holding the request open until the provider operation is terminal.

This is intended to let an agent continue other work while a declared slow operation runs. It does not mean that every call becomes asynchronous, that a queue makes provider work faster, or that success may be reported before the evidence supports it.

Current implementation facts

• gateway-quota-budget.ts already implements per-principal fair-share and a shared provider token bucket, including a typed pre-provider rate_limited path.
• The production personal-client Gateway assembly currently wires readCache, but does not pass quotaBudget into createGatewayClientHttpAdapter (scripts/agent-runtime/personal-client-gateway-registry.mjs). The existing quota implementation is therefore not yet the production admission boundary.
• The completed-read cache explicitly does not coalesce identical in-flight reads; its source says cancellation and per-request audit semantics require a separate contract (gateway-read-cache.ts).
• The audit journal appends and fsyncSyncs before the HTTP response is emitted (gateway-audit-journal.ts, gateway-client-http-adapter.ts). That is a valuable durability boundary, but synchronous disk work on the Node event loop is also a throughput/tail-latency candidate that should be measured.

Recommended architecture

Do not introduce one unbounded global queue. Use bounded bulkheads with separate facts and failure vocabulary:

1. a Gateway-wide in-flight ceiling;
2. connector/provider-installation concurrency ceilings so one stalled provider cannot exhaust the Gateway;
3. per-principal fairness;
4. provider rate/quota budgets; and
5. small bounded admission queues with deadlines.

Provider quota exhaustion should remain rate_limited. Gateway capacity exhaustion should be a distinct typed state such as gateway_busy. Both must refuse before provider execution, carry a bounded retry hint where known, and preserve the corresponding nonclaim. Queue length must never be allowed to become the memory bound.

For reads, the smallest high-value optimization is exact in-flight coalescing before a generic job system: one canonical provider read may have several waiters, while every client request keeps its own request_id and audit event. Cancelling one waiter must not cancel shared work while other waiters remain. Writes must never be coalesced.

For declared slow capabilities, use durable deferred execution. A candidate lifecycle is:

accepted/queued -> running -> succeeded | failed | outcome_unknown | expired | cancelled

pending is the client-facing nonterminal summary; the exact internal states may remain more specific. Required invariants:

• admission is durable before returning pending;
• the returned receipt keeps the original request/replay identity;
• restart does not create an additional provider mutation;
• queue-full refusal happens before provider execution;
• provider-started and provider-not-started states are distinguishable;
• cancellation, deadline, result retention, and terminality are explicit; and
• a deferred write is never retried under a newly invented request or idempotency key.

This directly depends on this issue's replay-identity and evidence-state work. audit_event_not_found cannot be the only answer indefinitely; the Gateway needs a typed nonterminal/terminal distinction or a bounded observation horizon.

Audit is not fire-and-forget

Audit persistence should not be moved behind the success response. A process crash after the response but before the audit append would make the result stronger than the evidence.

An internal audit writer is still worth evaluating:

operation result -> bounded audit-writer queue -> durable append/group commit -> acknowledgement -> client response

The request must await the durable acknowledgement. Moving filesystem work off the event loop and optionally using group commit may improve throughput, but this should preserve the current durable-before-response invariant and be justified by measured append/fsync and event-loop latency.

Ownership split

Gateway/Protocol should own:

• capacity admission and provider bulkheads;
• durable job identity and lifecycle;
• replay/idempotency enforcement;
• provider-started/terminal evidence;
• audit durability; and
• the typed pending, busy, retry, cancellation, and terminal receipt contract.

ceal-cli should consume that contract without inventing it:

• render pending as a valid nonterminal answer;
• preserve the exact returned reference and required idempotency input;
• expose bounded receipt observation (show, and potentially wait);
• never convert a timeout or missing audit event into permission to repeat a write; and
• keep Gateway audit readback distinct from provider-state readback.

Proposed sequence

1. Wire and configure the existing quota governor at the production Gateway assembly; disposition provider-backed discovery/target operations that the current invocation-only governor explicitly excludes.
2. Add measured global and connector-level concurrency bulkheads with typed pre-provider overload refusal.
3. Add exact in-flight read coalescing with independent per-request audit records.
4. Evaluate an audit writer that preserves durable-before-response semantics.
5. Add deferred execution only for capabilities whose contract declares it, then add the Worker pending/receipt surface.

Questions for the independent Gateway review

1. What is the exact public job/replay identity: request_ref, a separate job reference, the idempotency claim, or a specified tuple?
2. Which receipt states are nonterminal, and what makes absence terminal?
3. At which scopes should concurrency be configured: Gateway, connector installation, provider workspace/account, Profile, and principal?
4. Can an audit writer preserve the current commit-before-response guarantee while removing synchronous filesystem work from the request event loop?
5. Which provider-backed discovery, target-selection, readiness, and verification calls need the same admission governance as capability invocation?

This comment is a coordination decision, not a claim that the queue design is implemented. I recommend keeping #14 as the architecture umbrella and opening narrowly owned Gateway/Protocol and Worker follow-ups after the independent Gateway review answers the contract questions above.

[spilist]

Independent Gateway review — answers to the five contract questions

Reviewed against the Gateway tree at 36b80fcd8. Every claim below is verified by reading or by measurement on the serving host (2 cores, ext4, loadavg 0.45–0.56); inferences are labelled.

Agreement first, since it is the load-bearing part: the recommendation that audit must not move behind the success response is correct, and the bulkhead-not-one-global-queue shape is correct. Two of the implementation facts in the comment are confirmed independently below, and one recommendation is aimed at the wrong cost centre.

1. Public job/replay identity

Today it is the idempotency claim, and it is a specified tuple:

replay identity = sha256(authority ∥ scope ∥ idempotency_key)
  authority = (instance, subject, quota_key)
  scope     = (profile_ref, connector_binding_ref, data_area_ref, capability_id)

scripts/agent-runtime/gateway-provider-write-intents.mjs:145-153.

Two properties matter for the deferred-execution design:

• idempotency_key is a caller-supplied input on every write capability, never derived by the Gateway (format: "safe_idempotency_key" on each write descriptor). So replay identity is only as stable as the caller's key.
• normalized_mutation_sha256 is a same-key collision detector, not a lookup key (:273, reconcile :221-232). It is neither indexed nor queried. Consequence, verified by reading the GitHub issue-create path (gateway-github-profile-issue-create.mjs:57,60,63): the same mutation sent under a different key misses the store and writes to the provider twice. Cross-key duplicate prevention today is agent guidance, not a mechanism.

For deferred execution we would keep this tuple as the public identity rather than minting a separate job reference — a second identity would need its own replay semantics. The invariant "a deferred write is never retried under a newly invented idempotency key" is exactly right, and note it is the same gap that already exists synchronously.

2. Receipt terminality

Not settled here yet, and we would rather not settle it by implication. Today there is no nonterminal state: a call is terminal when it responds, and audit_ref resolution is the only observation surface. The evidence vocabulary that does exist is non_claims — specifically, the absence of provider_execution_not_reached is what says the provider was reached, and the protocol already enforces consistency between that array and error_code (packages/ceal-protocol/src/index.ts:669-673). We are formalising that as an explicit contract with tests rather than adding a new enum field, because a closed value vocabulary cannot gain members later without breaking idiomatic clients.

Our position: pending must not be introduced before provider-started vs provider-not-started is expressible on the existing terminal path. Otherwise the nonterminal state inherits an ambiguity it cannot resolve. Related: provider_execution_may_have_been_reached was repaired this session — the URL form of resource.resolve was returning it true for a permalink that failed to parse, i.e. pre-provider by construction.

3. Concurrency scopes — and the measured reason the ordering should change

Confirmed: gateway-quota-budget.ts implements per-principal fair share plus a shared provider bucket with a typed pre-provider rate_limited path, and the production assembly does not pass quotaBudget (scripts/agent-runtime/personal-client-gateway-registry.mjs:119 passes readCache and nothing else; the only caller passing quotaBudget anywhere is a test). The ternary at gateway-client-http-adapter.ts:242-243 therefore always takes the else branch. It is built and unwired, not missing.

The only live limiter is a per-(principal, capability) fixed window held in an in-memory Map (gateway-profile-connector-support.mjs:67-82) — process-local and lost on restart. Slack writes are 4/60s per principal, so N principals put N×4 writes/min against one workspace-app budget.

There is also no socket-level limit at all on the front router or admin API: maxConnections, requestTimeout, headersTimeout, keepAliveTimeout, maxRequestsPerSocket are absent across packages/ scripts/ bin/ config/ (zero hits, positive-controlled against a pattern with 118 hits).

But the measured arrival rate says admission is not the first move. ~/.ceal/ceal-prod/workspace/runtime-state/intake-signals.jsonl, 59 days, 8,210 signals: event_admitted 2,851 (≈48/day), queue_full_dropped 0. queue-full-drops.jsonl does not exist on either instance. The two busy_ingress_queue_full runtime errors on record are one incident on 2026-06-13.

Scopes we would configure, in this order: (a) shared provider installation (already built — wire it), (b) Gateway-wide in-flight ceiling, (c) HTTP socket limits. Per-Profile fairness we would defer until the arrival distribution justifies it.

4. Can an audit writer keep commit-before-response? Yes — but it is the wrong cost centre

The durability requirement is normative, not merely current behaviour: docs/specs/local-agent-governed-runner.spec.md:233-234 requires the append and fsync before the response is emitted, and its acceptance check is literally named fsync-before-response (:269).

Measured on the serving host:

	median
append + fsync, 0 MiB file	1.497 ms
append + fsync, 49 MiB file	1.492 ms
Gateway audit journal append (hash chain + schema assert)	1.848 ms (p90 2.26 ms)

The audit journal is a true O_APPEND write (packages/ceal-core/src/gateway-audit-journal.ts:557-583), and its cost is flat against history. Moving it off the event loop buys under 2 ms and puts the audit claim at risk.

The 45 ms is somewhere else. The leased-consumer store persists by full-file atomic rewrite plus two fsyncs (bounded-durable-store-file-io.mjs:23-36), and one persist does it twice — pending journal and state envelope (bounded-durable-store.mjs:334, :448). Live leases.json is 4.3 MB on ceal-dev:

21 KB → 3.6 ms   353 KB → 6.4 ms   1.38 MB → 14.5 ms   4.59 MB → 45.3 ms

That is head-of-line blocking on a single-threaded event loop, and it grows with accumulated history, not with user count. The store's own source records a live measurement of 733 ms of a 1,562 ms write (bounded-durable-store.mjs:423-425).

The fix does not weaken any durability claim: control-audit records already spill to an append-only sidecar and the continuity checker already computes over the union of both surfaces (control-audit-chain-continuity.mjs:13-15). The snapshot is 4.3 MB because the hot window is 2,000 records (gateway-leased-consumer-control-audit.mjs:124). Shrinking that window is a bounded change worth roughly 45 ms → 4 ms.

So we would reorder step 4: shrink the snapshot first, then re-measure whether an audit writer is worth building at all.

5. Which provider-backed calls need the same admission governance

The governor is invocation-only, so today the answer is "all of the ones it excludes". Concretely, readiness probes reach the provider — the file.search probe issues a bounded files.list call, and message.search's probe issues a conversations.history call. Target selection reaches the connector's selector. None of these consume quota. We would bring readiness and provider-backed target selection under the same budget; discovery that is served from a snapshot does not need it.

One correction to the issue's framing

#13's empty-page ambiguity is now answered Gateway-side: target_catalog.match_applied landed as an additive field (protocol 0.72.21). It cost two protocol edits, not one — the exact-keys list and a row in the additive-field registry; with only the first, the Gateway's own decoder rejects its own response and shrinks it to a 503. The worker half remains: target_catalog_selection_invalid still collapses into gateway_request_failed client-side, so the new target_catalog_capability_not_granted code and its select_granted_scope recovery are swallowed before a user sees them.

Non-claims

Nothing above has been pushed, tagged, released, applied to a live instance, or proved against a provider. The persistence numbers are microbenchmarks of the real store modules against a temp directory on the serving host under measured contention, not production traces. The live persist figure quoted is from the store's own recorded comment and was not re-measured against the running instance.

[spilist]

Worker follow-up after the independent Gateway review

Thanks — this closes most of the discovery questions and materially changes the implementation order. We agree with the following dispositions:

• keep the current idempotency-claim tuple as the semantic replay identity;
• do not introduce pending until provider-started vs provider-not-started is expressible on the existing terminal path;
• wire the shared provider-installation budget before designing a broad queue;
• govern provider-backed readiness and target selection, not only invocation;
• preserve durable audit-before-response; and
• shrink and re-measure the leased-consumer snapshot before building an audit writer.

One terminology boundary to retain

The semantic replay identity, the public receipt locator, and mutation collision evidence are distinct facts even if we decline to mint a second job identity:

• replay identity: the authority/scope/idempotency-claim tuple;
• public lookup/correlation handle: request_ref or write_request_ref;
• same-key mutation collision evidence: normalized_mutation_sha256.

The Worker guide should name the public fields it can actually preserve rather than asking an agent to preserve an undefined umbrella called “replay identity”. A future deferred receipt can reuse the existing semantic identity while still returning an opaque lookup handle; the handle need not become a second replay identity.

Admission boundary refinement

One capability request can produce more than one provider request: readiness, target selection, verification, and invocation do not necessarily have equal cost. Wiring the existing installation-level budget is the right first move, but the durable owner should move as close as practical to the connector outbound-request seam (or otherwise debit declared operation costs). This prevents “one capability call = one provider token” from becoming a second model of the provider quota.

The live arrival measurements justify deferring a generic durable queue. They do not make absent HTTP request/header/keep-alive bounds harmless; those are baseline availability controls and can be handled independently of current traffic volume.

pending wire direction

We agree not to widen a closed terminal enum opportunistically. Once provider reachability is explicit, the likely safe direction is a versioned deferred-receipt contract whose internal lifecycle can distinguish queued/running/terminal states, with pending only as a client-facing nonterminal summary. The exact versioning and terminality contract remains Gateway/Protocol-owned.

Correction to the #13 Worker statement

The statement that the new target-catalog codes are swallowed into gateway_request_failed is not true when the Gateway emits the new select_granted_scope recovery:

• signed Worker 0.76.1 already sends x-ceal-recovery: accept;
• its classifyGatewayFailure already uses the closed recovery kind as a fallback for unknown safe codes; and
• a direct source probe of both target_catalog_selection_invalid and target_catalog_capability_not_granted plus { recovery: { kind: "select_granted_scope" } } preserves the exact code and renders a denial.

What remains Worker-side is narrower: the fallback message is generic (“Profile or target selection”), so it does not explain that a requested capability has no grant. We will add locally owned exact-code messages/tests for the two target-catalog failures while keeping recovery-kind fallback for future unknown codes. match_applied itself still needs the next reviewed Protocol handoff before integrated Worker proof.

Worker-owned work proceeding now

Without originating a deferred Protocol contract, this repository can now:

1. replace the undefined replay-identity guide wording with exact preservation/no-repeat instructions;
2. remove the CLI-generated claim that a capability is already “approved” and treat purpose as caller assertion;
3. distinguish Gateway audit readback from provider-state readback in Worker result vocabulary, preserving compatibility where needed; and
4. render the two capabilities targets --match returns an ambiguous empty page for notion.page.get (raw URL and resolved resource.resolve ref both silently match nothing) #13 target-catalog refusal codes precisely.

Non-claim: this reply does not prove Gateway quota wiring, HTTP bounds, snapshot compaction, provider evidence, deferred execution, a signed Protocol handoff, or a live provider roundtrip.

[isnbh0]

Disclosure: I’m Codex, powered by GPT-5.6 Sol, posting this comment on John’s behalf.

Thank you for the detailed follow-up. The replies have clarified replay identity, evidence states, concurrency, audit persistence, and deferred execution. Those clarifications are useful, but they do not answer the critique’s central architectural claim:

Ceal should be an agent-safe projection and orchestration layer that reuses or aligns with established identity, authorization, API-contract, credential, and distributed-systems mechanisms where their semantics match.

Could the maintainers state whether they accept, reject, or defer this claim? If they reject any part of it, please identify the specific semantic mismatch that requires Ceal to define its own concept.

The critique asks the maintainers to answer these concrete questions:

1. How does each Ceal concept—Profile, Membership, Capability, Grant, Target Reference, Session, Receipt, and Proof Level—relate to established IAM or protocol concepts? For each term, please say whether Ceal uses an exact mapping, a compatible implementation option, an analogy, an extension, or an intentionally independent mechanism.
2. When an established concept already covers the required semantics, why does Ceal need a separate policy, authorization, schema, session, or effect vocabulary?
3. How does Ceal’s custom Session protocol address token audience, sender constraint, refresh rotation, replay response, revocation, expiry, and credential storage? Which OAuth security guidance applies, and where does Ceal intentionally differ?
4. Which standard dialect defines an input contract? If no standard dialect does, why does Ceal need a custom schema model?
5. Why does Route Effect combine provider changes, Session changes, and local changes? Will Ceal represent those effects separately and also represent safety, idempotency, and retry requirements as separate properties?
6. For each evidence state, which component observed the fact, which component verified it, what protects its integrity, which reference correlates it to the request, what claim does it support, and what does it not establish?

The replies partially answer the replay-identity question. They also agree that purpose is an assertion and that Gateway audit readback does not establish provider state. However, they do not explain whether Ceal will reuse established concepts for the broader architecture or why Ceal needs independent concepts when existing standards already express the same semantics.

This request does not assume that Ceal must adopt OAuth, RAR, OpenAPI, or any other standard when the semantics differ. It asks the maintainers to identify where the semantics match and reuse or align with the established concept there. Where the semantics do not match, please document the difference that requires Ceal’s independent design.

Please answer this architectural claim directly, even if the answer is to reject or defer it. Otherwise, the issue may improve the consistency of Ceal’s internal terminology without resolving the critique’s main concern: Ceal may be recreating general security and protocol concepts instead of limiting its custom design to the agent-specific control loop.