v1.1.0

v1.1.0 - Product Foundation Release

This release marks the first productization milestone after Chat Gun's v1.0.0 production-oriented Runtime release.

Building on the verified Runtime foundation completed through X21, v1.1.0 adds the product-level identity, data-governance, recovery, sandbox, secret, and network-control boundaries required to operate Chat Gun as a secure, recoverable, user-account-aware application.

Highlights

• Added product-grade consumer identity, account, session, credential, and tenancy lifecycle contracts
• Mapped authenticated product identity into the trusted Runtime ExecutionContext
• Added server-authoritative account, tenant, session, role, and entitlement resolution
• Added session issuance, renewal, expiry, revocation, and compromised-session containment
• Added anonymous-to-account migration with durable ownership preservation
• Added account lifecycle states for verification, recovery restriction, suspension, deletion, and tombstoning
• Added versioned data inventory and policy-driven retention across durable stores and projections
• Added durable consent, export, deletion, retention-expiry, and deletion-verification workflows
• Added idempotent and resumable subject-data deletion with completion receipts
• Added tombstone protection against replay, cache refill, and late-event recreation
• Added multi-instance runtime safety across shared durable state
• Added backup restoration and disaster-recovery validation
• Added configurable RTO / RPO and runtime readiness semantics
• Added crash and restore validation across checkpoints, approvals, streams, and side effects
• Added versioned Tool sandbox profiles for filesystem, process, resource, and network boundaries
• Added a SecretBroker boundary for late, scoped secret resolution
• Added network egress governance with redirect, DNS-rebinding, encoded-address, localhost, and private-network protection
• Added fail-closed behavior when privileged Tool sandbox or secret dependencies are unavailable
• Added automated leakage protection preventing plaintext credentials from entering model context, events, checkpoints, receipts, logs, or traces

Consumer Identity & Account Lifecycle

Chat Gun now has a product-level identity boundary above the existing Runtime authorization layer.

The product distinguishes identities such as:

AccountId
UserId
TenantId
SessionId
DeviceId
CredentialId
PrincipalId

External identity-provider claims are validated and mapped server-side into the trusted Principal used by the Runtime.

Clients may present credentials, but they cannot directly assert:

• Runtime roles
• Tenant membership
• Billing ownership
• Approval authority
• Privileged execution scope

The Runtime continues to treat trusted identity as server-authoritative.

Account lifecycle now includes explicit states such as:

pending_verification
active
recovery_restricted
suspended
deletion_pending
deleted / tombstoned

Session and credential lifecycle behavior now covers:

• Issuance
• Renewal and rotation
• Idle expiry
• Absolute expiry
• Per-session revocation
• Revoke-all
• Compromised-session containment

Revocation affects new Runtime steps and durable resumptions without requiring a process restart.

Anonymous-to-Account Migration

Anonymous activity can now be migrated into an authenticated account without relying on display names, browser-local identity, or client-supplied ownership claims.

Migration is designed to preserve ownership of:

• Conversations
• Artifacts
• Approvals
• Runtime history
• Usage records

The migration path is idempotent, resumable, and protected against partial account linking.

This prevents a partially completed identity transition from creating cross-account ownership ambiguity.

Data Governance & Subject Rights

Privacy and retention behavior are now represented as durable product workflows rather than scattered storage-specific delete operations.

The product maintains a versioned data inventory describing:

• Authoritative store
• Data owner / subject
• Purpose
• Sensitivity
• Retention policy
• Export behavior
• Deletion behavior
• Audit / legal exceptions
• Derived projections and caches

Durable workflows now cover:

data export
account deletion
consent withdrawal
retention expiry
deletion verification

Deletion is coordinated across registered durable stores and derived projections.

A successful deletion request therefore means more than deleting one database row.

The workflow records which stores were:

completed
skipped
retained_by_policy
failed

and produces a non-sensitive deletion receipt.

Retention, Consent & Tombstones

Retention policy is versioned and policy-driven.

Optional processing such as:

• Personalization
• Evaluation contribution
• Proactive background activity

can be tied to explicit consent records rather than unstructured consent text.

Consent withdrawal changes future processing behavior without rewriting historical facts.

Deleted identities and resources receive tombstone protection so they cannot silently reappear through:

• Event replay
• Cache refill
• Derived indexes
• Late-arriving events
• Recovery workflows

Minimum security or accounting evidence that must remain is explicitly separated from mutable user data and minimized according to policy.

Multi-Instance Runtime & High Availability

Chat Gun can now reason about execution across multiple application/runtime instances using shared durable state.

Process-local assumptions are removed or governed for areas such as:

• Run ownership
• Job ownership
• Session revocation
• Approval resume
• Notification deduplication
• Maintenance leases

Runtime health is no longer represented by a single process-alive signal.

Readiness can distinguish:

process alive
dependency reachable
safe to accept new work
safe to resume durable work
degraded read-only mode

This allows deployment and operations tooling to reason about whether an instance can safely handle the class of work it advertises.

Backup & Disaster Recovery

Authoritative stores now have an explicit backup and restore model.

The recovery model covers:

• Runtime persistence
• Object storage
• Configuration metadata
• Encryption-key dependencies
• Durable execution evidence

Restore is validated in an isolated environment before being treated as usable recovery evidence.

Configured deployment policy may define:

RTO
RPO
availability target
latency / error budget

These values are operational policy and measured evidence rather than hard-coded source constants.

The restore path preserves side-effect truth.

A recovered system never blindly repeats an external mutation merely because local state was restored from backup.

Crash & Recovery Safety

Recovery validation covers critical execution boundaries such as:

before external effect
after external effect / before local acknowledgement
during approval wait
during streaming
during checkpoint resume

Durable side-effect identities and idempotency records remain valid across worker replacement and restore.

If restored local state and an external system may disagree, the Runtime creates reconciliation work rather than inventing a successful local state.

Recovery scans are bounded and rate-limited so recovery itself cannot create a retry storm or second incident.

Tool Sandbox Profiles

Tool execution now has an operating-system and resource-containment boundary in addition to Runtime authorization.

Versioned execution profiles can govern:

• Filesystem roots
• Read / write modes
• Process creation
• CPU limits
• Memory limits
• Disk limits
• Wall-clock limits
• Available binaries
• Runtime images
• Output limits
• Temporary artifact handling
• Network destinations
• Protocols
• DNS behavior
• Environment exposure

A Tool must resolve to an explicit execution profile or be denied.

Sandboxing does not replace authorization.

The execution order remains:

Trusted Identity
→ Authorization
→ Tool Policy
→ Sandbox / Egress Profile
→ Secret Resolution
→ Tool Execution

A permitted Tool cannot automatically escape its sandbox, and a sandboxed Tool does not automatically gain permission.

Secret Brokering

Secrets are now treated as opaque references instead of Runtime payloads.

The SecretBroker resolves credentials only at the final authorized execution boundary and as late as possible.

Plaintext secret values must not enter:

• ExecutionContext
• Model prompts
• Tool schemas
• Tool arguments
• Runtime events
• Checkpoints
• Audit records
• Receipts
• Logs
• Traces
• Crash diagnostics

Where providers support it, execution may use short-lived and scope-restricted credentials.

Secret-broker failure produces a typed infrastructure failure rather than silently falling back to insecure execution.

Network Egress Governance

Network access now follows explicit per-Tool egress policy rather than unrestricted outbound connectivity.

Egress validation accounts for attack classes such as:

redirect escape
DNS rebinding
encoded IP addresses
localhost access
private-network traversal
URL parser disagreement
secondary connections

Redirected or secondary connections must be re-evaluated against the same network policy.

String-prefix URL checks are not treated as sufficient security controls.

Sandbox Failure Safety

The Runtime explicitly handles sandbox failures including:

• Startup timeout
• Missing execution image/runtime
• Resource quota exhaustion
• Secret-broker unavailability
• Credential expiry
• Forced termination
• Oversiz...

v1.0.0

v1.0.0 - Production-Oriented Release

This release marks the completion of Chat Gun's second-stage Runtime hardening and integration roadmap.

Following the feature, operational, integration, context, event, and recovery work completed across the previous release candidates, v1.0.0 validates the full end-to-end Runtime path through a production readiness gate covering execution safety, recovery, authorization, observability, compatibility, context control, side-effect integrity, and failure handling.

Highlights

• Completed the end-to-end Runtime Production Readiness Gate
• Validated the full execution path from input through BFF, Agent Server, Graph, Model, Tool, persistence, runtime events, and frontend-consumable output
• Verified canonical runId correlation across events, audit records, traces, ToolExecution, and terminal results
• Added architecture checks that prevent protected Tools from bypassing the governed execution pipeline
• Verified production Tool registries cannot operate without trusted authorization
• Verified mutation Tools cannot execute without side-effect identity and reconciliation semantics
• Verified runtime event producers use versioned event contracts
• Verified Agents no longer rely on legacy context assembly paths
• Verified trusted identity cannot originate from client-controlled metadata
• Validated authorization, tenant isolation, and self-approval protection
• Validated duplicate side-effect prevention under retry, resume, timeout, and restart
• Validated context hard limits, compression behavior, Memory degradation, and current-intent priority
• Validated terminal-state monotonicity under duplicate, late, replayed, and out-of-order runtime events
• Validated durable HITL, clarification resume, cancellation, and crash-safe conversation recovery
• Validated ExecutionManifest compatibility across compatible, migratable, and incompatible resume scenarios
• Validated deployment drain, stuck-Run recovery, and ambiguous side-effect reconciliation
• Added fault-injection and release-gate coverage across provider, Tool, storage, stream, recovery, and runtime failure boundaries
• Established the integrated Runtime Canary as part of release readiness validation

End-to-End Runtime Validation

v1.0.0 validates the integrated execution path rather than treating individually tested Runtime modules as sufficient evidence of readiness.

The validated execution path is:

User Input
→ BFF
→ Agent Server
→ Graph
→ Model
→ Tool
→ Authorization / HITL
→ ToolExecution / Side-effect Runtime
→ Persistence
→ Runtime Events
→ Frontend-consumable Output
→ Recovery / Resume

Each layer participates in the same authoritative execution model.

The Runtime does not introduce a second queue, worker system, checkpoint authority, or parallel Tool execution path.

LangGraph Agent Server remains responsible for native Run, queue, worker, checkpoint, and interrupt behavior, while Chat Gun extends that lifecycle with business Task / Step semantics, authorization, side-effect governance, interaction ownership, context control, event contracts, and recovery policy.

Production Readiness Gate

The final release gate now requires all critical Runtime dimensions to pass together:

Deterministic unit and contract tests pass
AND

Cross-package lint / test / build pass
AND

Runtime boundary live validation passes
AND

No authorization or tenant-isolation regression
AND

No duplicate side-effect regression
AND

No terminal-state monotonicity regression
AND

Recovery remains inside configured bounds
AND

Context remains inside the hard model limit
AND

Cost and latency remain inside versioned tolerances
AND

ExecutionManifest compatibility policy passes

A successful process start or /health response is not considered sufficient evidence of Runtime readiness.

Release approval is based on integrated execution behavior under controlled fault injection and compatibility validation.

Runtime Safety & Authorization

The final Runtime path preserves trusted identity and authorization from request entry through Tool execution.

The gate verifies:

• Trusted Principal and Tenant context cannot be overridden by client metadata
• Cross-tenant resource access fails before Tool dispatch
• Protected Tools cannot bypass authorization
• Sensitive operations cannot self-approve
• Durable HITL survives process restart
• Expired, replayed, mismatched, and unauthorized approvals are rejected
• Authorization denial never enters automatic retry

Security-critical execution paths fail closed when mandatory identity, policy, authorization, or execution dependencies are unavailable.

Side-Effect Integrity

Mutation Tools continue to use durable execution identity, business-effect idempotency, and reconciliation instead of distributed exactly-once assumptions.

The final gate verifies cases such as:

Tool side effect commits
→ response is lost
→ process restarts
→ Runtime reconciles external state
→ committed effect is detected
→ no duplicate mutation occurs

The Runtime distinguishes:

replay identity
request deduplication
business effect identity
external operation identity

An ambiguous side-effect result never becomes permission for blind retry.

Committed, unknown, reconciled, compensated, and manual-intervention states remain explicitly distinguishable.

Runtime Events & Terminal Safety

Versioned Runtime Event contracts are now part of the production readiness boundary.

Events carry:

schemaVersion
eventId
sequence
type
emittedAt
execution context
payload

The gate validates:

• Duplicate event delivery
• Bounded out-of-order delivery
• Replayed events
• Late events
• Unknown future event types
• Disconnect and reconnect
• Checkpoint replay
• Superseded Runs

Terminal execution state remains monotonic.

For example:

running
→ completed

late progress event arrives
→ state remains completed

A stale or superseded Run cannot overwrite the current authoritative Run.

Context, Compression & Memory Safety

The Runtime now validates context behavior as part of release readiness rather than treating it only as a model-quality concern.

The gate verifies:

• Model input remains within configured hard limits
• Security and current-task content follow approved retention priorities
• Compression occurs before eligible low-priority context is dropped
• Compression failure has deterministic fallback behavior
• Memory unavailability degrades according to policy
• Current explicit user intent overrides conflicting historical Memory
• Deleted, unauthorized, or stale Memory cannot silently re-enter active context
• Legacy fixed last-N context assembly paths are not used by production Agents

Durable Recovery

Recovery behavior is validated across process failure, checkpoint resume, waiting HITL, Tool execution, and side-effect ambiguity.

The Runtime distinguishes:

not_started
executing
committed
unknown
terminal
waiting_user

Recovery decisions depend on the last durable execution state.

Committed mutations are preserved.

Unknown mutations reconcile before continuation.

Incompatible execution state follows explicit:

migrate
pin
park

policy rather than blind replay.

The gate also validates:

• Process termination before checkpoint
• Process termination during HITL
• Process termination during Tool execution
• Process termination after external commit
• Deployment restart
• Stuck Run recovery
• Deployment drain
• Redis / PostgreSQL degradation
• Manual parking when safe continuation cannot be proven

Fault Injection Coverage

The production readiness matrix covers failure scenarios across the full Runtime.

Validated categories include:

• Invalid or truncated provider responses
• Provider timeout, refusal, or unavailability
• Malformed, oversized, incomplete, or schema-invalid Tool arguments
• MCP loading, authentication, disconnect, and timeout failures
• Authorization allow, deny, confirm, expiry, replay, and cross-tenant cases
• Retry recovery and Retry Budget exhaustion
• Side-effect commit followed by response loss
• Redis and PostgreSQL unavailability
• Audit / telemetry degradation
• User cancellation and client disconnect
• Run supersession
• Clarification resume
• Duplicate submission
• Runtime event duplication, reordering, replay, and late delivery
• Context overflow and compression timeout
• Memory unavailability and conflicting Memory
• Worker or process termination
• Compatible, migratable, and incompatible ExecutionManifest resume
• Deployment drain and stuck-Run recovery
• Cost and latency regressions
• Deliberate Hard Negative behavior regressions

Architecture Enforcement

This release also treats architectural bypasses as release failures.

Automated checks prevent:

• Direct protected Tool invocation
• Mutation Tools without side-effect descriptors
• Production Tool registries without authorization
• Unversioned Runtime Event producers
• Agents using legacy context assembly
• Trusted identity sourced from client-controlled metadata

The intended Runtime behavior is therefore enforced through executable contracts and tests rather than architecture documentation alone.

Integrated Runtime Canary

The Runtime Canary now exercises the real execution composition root using safe test resources.

The canary validates:

Create Runtime input
→ establish trusted execution context
→ execute Graph / Step
→ invoke safe Tool
→ persist Task / Step / ToolExecution
→ emit versioned Runtime Events
→ interrupt / checkpoint
→ resume
→ verify authorization evidence
→ verify Audit
→ verify Trace
→ ...

v1.0.0-rc.4

v1.0.0-rc.4 - Runtime Context, Event & Recovery Candidate

This release completes the remaining runtime context, event-contract, and durable recovery integration work before Chat Gun's final end-to-end production readiness gate.

Following the integrated execution path established in v1.0.0-rc.3, this release activates governed context assembly across Agents, introduces versioned and monotonic runtime event contracts, and makes HITL, clarification, cancellation, and conversation recovery durable across process restarts and execution failures.

Highlights

• Activated shared Context Budget, compression, and governed Memory across production Agent paths
• Replaced legacy fixed last-N and unbounded conversation assembly with priority-based context construction
• Preserved security rules and current-task context within explicit model limits
• Added deterministic degradation when compression, Memory retrieval, or token estimation fails
• Integrated authorized long-term Memory into context assembly without allowing historical Memory to override current explicit user intent
• Added redacted Context manifests with source, priority, estimated-token, compression-action, and policy metadata
• Introduced versioned runtime event envelopes with stable eventId, Run-scoped sequence numbers, timestamps, and canonical execution correlation
• Added deterministic duplicate, replay, late-event, and bounded out-of-order handling
• Enforced monotonic terminal-state behavior so completed or failed Runs cannot return to running because of delayed events
• Added compatibility handling for existing unversioned runtime events
• Added durable HITL and clarification state that survives process restart
• Added one-time, scoped, validated resume semantics for waiting Tasks
• Added recovery sanitization for incomplete Tool/message history and protocol-invalid persisted state
• Added explicit recovery classification for not_started, executing, committed, unknown, terminal, and waiting_user execution states
• Routed committed and ambiguous mutation recovery through ToolExecution reconciliation before continuation
• Kept user cancellation, transport disconnect, timeout, supersession, crash, and authorization expiry as distinct runtime outcomes
• Added deterministic park/manual-recovery behavior when persisted state cannot be proven safe to resume

Context Budget, Compression & Governed Memory

Context construction now runs through a shared runtime boundary instead of Agent-specific last-N or unbounded conversation assembly.

The Runtime assembles context using explicit priority and policy rather than relying on raw message position alone.

Context inputs may include:

• System and security policy
• Current Task and active execution state
• Related authorized resources
• Governed long-term Memory
• Recent conversation
• Tool results

The Runtime applies configured compression before dropping eligible lower-priority content.

When compression fails, times out, or is cancelled, the system falls back to deterministic truncation rather than emitting an oversized model request.

Historical Memory is injected only when authorized and relevant.

Current explicit user input always retains higher authority than:

• Historical preferences
• Accepted historical choices
• Model-inferred Memory
• Previous conversation summaries

Low-confidence inferred Memory cannot become a Hard Constraint simply because it appears in persistent storage.

Context Failure Handling

Context construction now has explicit degraded and terminal outcomes.

Examples include:

P0 / mandatory context exceeds hard model limit
→ terminal configuration error
→ do not send oversized model request

Memory unavailable
→ continue without Memory only when policy allows
→ emit degraded runtime event

Compression invalid or unavailable
→ discard invalid compressed output
→ use deterministic fallback

Token estimator unavailable
→ use conservative byte-based estimation
→ emit observable reason code

The Runtime also emits a redacted Context manifest describing:

• Source references
• Priority
• Estimated tokens
• Compression decisions
• Policy version

without persisting unrestricted prompts, raw Tool output, or sensitive content by default.

Versioned Runtime Event Contract

Runtime events now use an explicit versioned envelope rather than relying on loosely structured stream payloads.

The canonical event shape includes:

schemaVersion
eventId
sequence
type
emittedAt
context
payload

Every event carries canonical execution correlation so activity can be traced back to the authoritative Run.

The event contract now covers runtime activity across:

• Run
• Task
• Step
• Model
• Tool
• Permission
• Reconciliation
• Compensation
• Context
• Card
• Terminal states

Terminal outcomes are represented using stable machine-readable states rather than inferred from display text or localized messages.

Supported terminal semantics include:

completed
failed
cancelled
timed_out
crashed
budget_exhausted
needs_user
superseded
manual_intervention_required

Event Ordering & Monotonicity

The frontend runtime reducer now treats runtime events as deduplicable and order-aware data.

Events are:

• Deduplicated by stable eventId
• Ordered using Run-scoped monotonic sequence
• Buffered only within bounded reordering limits
• Correlated with authoritative Run generation
• Forward-compatible with unknown event types and future payload fields

A terminal execution cannot return to running because of a replayed or late progress event.

For example:

running
→ completed

late step_progress arrives
→ ignored for state transition
→ optionally recorded as observable late event
→ state remains completed

Likewise, output from a superseded Run cannot replace the currently authoritative Run.

Durable HITL & Resume

Human-in-the-loop and clarification flows now survive process restarts.

Persisted waiting state includes:

• Interrupt identity
• Run / Task / Step correlation
• Expected response schema
• Expiry
• Authorization scope
• Resume compatibility metadata

A resume response must be:

• Authorized
• Schema-valid
• Scoped to the intended waiting execution
• Compatible with the persisted execution state
• Consumed at most once

Expired, replayed, mismatched, or unauthorized resume payloads do not advance the Graph.

The Agent cannot approve its own protected action.

Crash-Safe Conversation Recovery

Conversation recovery now validates persisted protocol state before execution resumes.

The recovery sanitizer detects and handles cases such as:

• Unmatched Tool calls and Tool results
• Incomplete Tool argument fragments
• Orphaned reasoning or content blocks
• Partial assistant messages
• Invalid legacy configuration values
• Already-terminal Tool results
• Incompatible Execution Manifests

The Runtime classifies the last durable execution point as:

not_started
executing
committed
unknown
terminal
waiting_user

Recovery behavior depends on that state.

For mutation work:

committed
→ preserve effect truth
→ do not replay blindly

unknown
→ reconcile through governed Tool execution
→ retry only if downstream is proven not committed

cannot prove safe continuation
→ park for manual recovery

Persisted transcript content alone is never treated as proof that an external side effect occurred.

Recovery Semantics

Runtime recovery now distinguishes conditions that previously risked being conflated:

client_disconnect
user_cancel
timeout
superseded
authorization_expired
process_crash
manual_intervention_required

A client disconnect is not treated as a business cancellation.

A user cancellation does not automatically imply rollback.

A process restart does not authorize replay of a committed mutation.

An incompatible checkpoint or Execution Manifest follows explicit:

migrate
pin
park

policy rather than blind resume.

Failure Safety

This release strengthens fail-safe behavior across Context, Events, and Recovery.

The Runtime now follows these principles:

• Invalid context is never sent merely to keep the Run alive
• Invalid event ordering cannot reopen a terminal execution
• Duplicate events do not duplicate state transitions
• Invalid resume payloads do not advance waiting Tasks
• Ambiguous side effects reconcile before continuation
• Protocol-invalid conversation state is sanitized or parked, not invented
• Fatal runtime corruption stops new work instead of pretending the process remains healthy

Related Pull Requests

• #116
• #117
• #118

Release status

v1.0.0-rc.4 completes the planned Runtime integration path before the final production readiness gate.

The project now has an integrated execution model covering:

• Canonical execution identity and correlation
• Trusted Principal / Scope authorization
• Durable confirmation and HITL
• Unified governed Tool execution
• Typed provider and Tool-call decoding
• Descriptor-driven scheduling and resilience
• Normalized runtime input
• Query re-entry and duplicate-submit protection
• Context Budget and compression
• Governed long-term Memory injection
• Versioned runtime events
• Terminal-state monotonicity
• Durable clarification and approval resume
• Crash-safe conversation recovery
• Side-effect-aware recovery and reconciliation

At this stage, the remaining work before v1.0.0 is no longer another Runtime feature layer.

The remaining milestone is to prove that the integrated end-to-end runtime path satisfies the project's safety, recovery, observability, compatibility, and performance req...

v1.0.0-rc.3

v1.0.0-rc.3 - Integrated Runtime Execution Candidate

This release advances Chat Gun from individually validated runtime primitives toward a single integrated production execution path.

Following the operational hardening completed in v1.0.0-rc.2, this release connects the LangGraph runtime boundary, canonical execution context, trusted authorization, governed Tool dispatch, typed provider decoding, resilience policies, and normalized input handling into one coordinated Runtime path.

Highlights

• Re-verified the current LangGraph Agent Server runtime and persistence boundary against the deployed architecture
• Established a canonical ExecutionContext shared across BFF, Agent Server, Graph, model, Tool, Task, Audit, tracing, and terminal responses
• Unified requestId, threadId, runId, taskId, stepId, toolCallId, and authorization context under one validated runtime identity contract
• Wired trusted Principal / Tenant / Scope authorization into the production Tool dispatch path
• Added durable HITL confirmation handling for protected and sensitive Tool actions
• Enforced fail-closed behavior for missing identity, authorization, risk, or mandatory runtime dependencies
• Added a unified Tool execution pipeline covering validation, authorization, retry, side-effect safety, reconciliation, compensation, audit, and tracing
• Prevented mutation Tools from registering without stable replay and business-effect identity
• Added architecture checks to prevent protected production Tools from bypassing the governed dispatcher
• Replaced silent malformed Tool-argument fallback behavior with bounded and typed decode outcomes
• Added explicit handling for incomplete, invalid, oversized, refused, and schema-invalid provider / Tool-call results
• Added descriptor-driven scheduling, concurrency, retry, rate-limit, and circuit-breaker policies
• Added conservative serial execution for mutation, destructive, unknown, or classification-failed Tool calls
• Added a shared normalized input contract for prompts, attachments, clarification resumes, cancellation, and commands
• Added generation-based query re-entry protection to prevent duplicate authoritative Runs during async dispatch
• Added request idempotency for double-submit, reconnect, and repeated user input

Runtime Integration Foundation

This release re-establishes the authoritative ownership boundary between LangGraph Agent Server and Chat Gun's custom Runtime layers.

LangGraph remains responsible for:

• Run scheduling and worker assignment
• Thread / Run lifecycle
• Checkpoint and interrupt semantics
• Native resume behavior

Chat Gun continues to extend those capabilities with:

• Business Task / Step state
• Active-run ownership and generation control
• Side-effect execution truth
• Authorization and permission governance
• ToolExecution reconciliation
• Long-term memory governance
• Operational recovery classification

The runtime no longer treats threadId, request identity, Task identity, and Run identity as interchangeable concepts.

A canonical ExecutionContext now carries the authoritative runtime identity through the execution chain:

Browser
→ BFF
→ Agent Server
→ Graph
→ Model
→ Tool
→ Task / Step
→ Authorization
→ ToolExecution
→ Audit
→ OTel / Opik
→ Runtime Events
→ Terminal Response

This makes one Run traceable across the full system without relying on process-global mutable state or loosely correlated metadata.

Trusted Authorization & Durable HITL

Trusted identity and authorization are now part of the mandatory production execution path rather than isolated governance primitives.

Protected Tool actions now resolve:

• Trusted Principal identity
• Tenant boundary
• Active Runtime Scope
• Resource ownership and ResourceRef
• Roles and permission grants
• Tool risk classification
• Versioned authorization policy
• Durable confirmation state

Sensitive actions can enter a durable HITL flow before Tool dispatch.

The runtime rejects:

• Forged client identity overrides
• Cross-tenant resource access
• Unregistered protected Tools
• Expired or replayed approvals
• Mismatched Run or resource confirmations
• Agent self-approval or self-elevation paths

Authorization decisions are persisted before protected Tool execution and correlated with the resulting ToolExecution when applicable.

Unified Tool Dispatch Pipeline

This release introduces one governed Tool execution path shared by production Agents.

The runtime execution pipeline now follows:

Tool Call Decode
→ Input Schema Validation
→ Runtime Tool Descriptor Resolution
→ Authorization / Durable HITL
→ Concurrency Scheduling
→ Task / Step Start
→ Side-effect Prepare
→ Retry Budget
→ Tool Dispatch
→ Output Schema Validation
→ Reconciliation when ambiguous
→ Compensation / Manual Parking when required
→ Structured Tool Result
→ Task Event + Audit + Trace

Read-only and mutation Tools share the same governed boundary, while mutation Tools additionally require durable side-effect semantics.

A mutation Tool cannot register unless it defines the identities and reconciliation behavior required to answer:

• Is this the same logical Tool call?
• Has the business effect already committed?
• Is the downstream outcome known?
• Is retry safe?
• Is reconciliation required?

The runtime does not claim distributed exactly-once execution.

Instead, it uses stable replay identity, business-effect idempotency, durable persistence, and reconciliation to prevent unsafe duplicate effects.

Provider & Tool Call Decoding

Provider responses and Tool arguments now use bounded typed decoding rather than permissive fallback behavior.

Malformed Tool arguments no longer silently become:

{}

unless the provider actually returned a valid empty object.

Decode outcomes are now distinguishable as:

valid
incomplete
invalid
too_large
schema_invalid
refused

The Runtime also preserves structured diagnostics such as:

• Provider identity
• Endpoint kind
• Finish reason
• Request correlation
• Payload byte length
• Redacted / hashed diagnostic identity

Eligible malformed or truncated output may receive at most one bounded repair attempt.

Every repaired candidate must still pass strict JSON decoding and the Tool input schema before execution.

Tool Scheduling & Resilience

Concurrency and retry behavior are now descriptor-driven rather than inferred from Tool names or individual implementations.

The Runtime now distinguishes:

• Concurrency-safe read-only Tools
• Mutation Tools
• Destructive Tools
• Unknown or classification-failed Tools

Safe read-only Tools may execute concurrently within configured limits.

Mutation and unknown Tools execute serially.

Retry behavior is restricted to definitive retryable outcomes.

For mutation Tools:

ambiguous outcome
→ reconcile
→ committed
   → do not retry

→ not_committed
   → retry only within Retry Budget

→ unknown
   → stop automatic replay / park / escalate

Authorization denial, user cancellation, business rejection, schema failure, and unresolved side-effect state are never automatically retried.

Normalized Input & Query Re-entry Guard

This release also establishes a shared input contract for runtime entry.

Supported inputs now normalize into explicit runtime commands such as:

prompt
clarification_resume
cancel
command

Raw user input remains separate from normalized input so transport normalization does not overwrite original user intent.

The runtime now applies:

• Unicode and whitespace normalization
• Attachment reference validation
• Command separation before Graph execution
• Generation-based dispatch ownership
• Duplicate-submit idempotency
• Clarification-resume routing
• Cancel / enqueue / supersede interaction policies

The query guard is reserved before asynchronous dispatch begins, preventing two authoritative Runs from entering through the same interaction scope during an async normalization or queue gap.

Stale cleanup from an older Run also cannot clear or overwrite a newer authoritative Run.

Related Pull Requests

• #102
• #103
• #104
• #105
• #106
• #107
• #108
• #115

Release status

v1.0.0-rc.3 marks the point where Chat Gun's previously independent Runtime primitives are now substantially integrated into a single governed execution path.

The project now has an integrated foundation covering:

• Canonical Run and execution correlation
• Trusted identity and authorization
• Durable HITL
• Unified Tool dispatch
• Side-effect safety and reconciliation
• Typed Tool / provider decoding
• Descriptor-driven scheduling and resilience
• Normalized runtime input
• Query re-entry and duplicate-submit protection

The remaining work before the final v1.0.0 release is focused on completing the remaining cross-layer contracts and proving crash-safe recovery across the integrated Runtime.

Next milestone

X18 + X19 → v1.0.0-rc.4

The next release candidate will focus on:

• Activating context budget, compression, and governed Memory across every Agent
• Removing legacy last-N and unbounded context assembly paths
• Introducing versioned runtime event envelopes
• Adding stable event IDs and Run-scoped sequence ordering
• Enforcing monotonic terminal-state behavior
• Making reconnect, replay, duplicate, late, and out-of-order event handling deterministic

After that:

X20
→ v1.0.0-rc.5
→ Durable Recovery Candidate

X21 Production Readiness Gate
→ v1.0.0
→ Production-Oriented Release

Status

Chat Gun remains a production-oriented, pre-production validation project.

v1.0.0-rc.3 represents an integrated Runtime execut...

v1.0.0-rc.2

v1.0.0-rc.2 - Release Validation Candidate

This release completes Chat Gun's planned post-feature operational hardening work for the second-stage architecture.

Following the feature-complete v1.0.0-rc.1, this release adds governed long-term memory, runtime operations, recovery semantics, deployment safety, execution compatibility, live canary validation, and release gates required before the final v1.0.0 milestone.

Highlights

• Added scope-aware and versioned long-term memory governance on top of the runtime memory boundary
• Separated memory visibility from write authority using explicit read and write scope policies
• Added provenance, confidence, revision, expiration, and namespace metadata to long-term memory records
• Added optimistic concurrency control to prevent stale memory updates from silently overwriting newer state
• Added bounded memory revision history and restore-as-new-revision behavior
• Enforced current explicit user intent over conflicting historical memory
• Integrated authorized memory retrieval with existing context budget governance
• Added runtime SLO and external metrics aggregation contracts
• Added worker health, heartbeat, stuck-run detection, and lost-run recovery semantics
• Added manual parking and reconciliation paths for unsafe or ambiguous executions
• Added graceful deployment drain for in-flight durable work
• Added ExecutionManifest tracking for runtime, graph, prompt, model, tool, and policy versions
• Added compatibility policies for resume, migration, pinning, and manual recovery across runtime versions
• Added operational failure drills and recovery runbooks
• Added version-pinned evaluation and release gates
• Added bounded live Runtime Canary validation across persistence, Tool execution, interrupt/resume, Audit, and tracing

Long-Term Memory Governance

Long-term memory is now governed as durable runtime state rather than unrestricted conversation history.

Memory records are isolated by tenant, principal, domain, and scope, and include structured provenance, confidence, revision, retention, and authorization metadata.

The runtime now distinguishes:

• Memory that is visible to the active scope
• Memory that the active scope is allowed to modify
• Current explicit user intent
• Historical preferences and accepted choices
• Model-inferred memory with lower authority

Current-turn explicit intent always takes precedence over historical memory.

Low-confidence inferred memory cannot silently become a Hard Constraint, and stale writers cannot overwrite newer revisions without re-reading and reconciling the latest state.

Memory history remains inspectable, while restoring a historical value creates a new revision instead of mutating previous records.

Runtime Operations & Recovery

This release adds the operational control plane required to reason about long-running and recoverable Agent execution.

Runtime operations now cover:

• Task, Step, Tool, retry, compensation, and side-effect metrics
• Runtime SLO / SLI definitions
• Worker heartbeat and execution health
• Stuck and abandoned Run detection
• Replay-safe recovery
• Manual parking for unsafe execution states
• Side-effect reconciliation before retry
• Graceful deployment drain
• Runtime version compatibility and execution manifests

Unsafe side-effect states are never blindly replayed.

When an external effect is ambiguous, the runtime must reconcile the persisted ToolExecution state before deciding whether execution can safely resume, retry, or requires manual intervention.

Execution Compatibility

Every durable execution can now record an ExecutionManifest covering the versions that materially affect execution behavior, including:

runtimeBuildId
graphVersion
promptVersion
modelRouteVersion
toolSchemaVersion
policyVersion
domainSchemaVersion
catalogVersion
embeddingVersion
rerankerVersion

Resume behavior is explicitly classified as:

compatible
→ resume

migratable
→ migrate state/schema, then resume

incompatible
→ pin previous environment or park for manual recovery

Deployment of a newer runtime version does not by itself authorize replay of write or side-effect Steps.

Release Validation

This release introduces explicit pre-release validation gates rather than treating a successful build or /health response as sufficient evidence of runtime readiness.

The release gate now considers:

• Deterministic regression suites
• Business Constraint regressions
• Duplicate side-effect prevention
• Runtime recovery behavior
• Execution Manifest compatibility
• Cost and latency regressions
• Version-pinned evaluation datasets

A deliberate Hard Negative, duplicate side-effect, recovery, or compatibility regression must fail the release gate.

Live Runtime Canary

A bounded live canary validates the deployed runtime through an actual execution path:

Create Task
→ execute Step
→ persist Task / Step / Event
→ invoke safe Mock Tool
→ interrupt / checkpoint
→ resume
→ verify Audit
→ verify OTel trace
→ verify no duplicate side effect

The canary records the active Runtime Build and Execution Manifest so deployment health is tied to actual runtime behavior rather than process availability alone.

Related Pull Requests

• #87
• #89
• #92

Issues Fixed

• #79
• #90

Release status

v1.0.0-rc.2 completes the planned feature path and post-feature operational hardening work for the second-stage architecture.

The remaining work before the final v1.0.0 release is focused on cross-system validation rather than introducing new core runtime capabilities.

The final release requires the remaining integration acceptance checks to pass across:

• Runtime persistence and recovery
• Side-effect replay protection and reconciliation
• Authorization and tenant isolation
• Active-run interaction safety
• Recommendation Hard Negative validation
• Long-term memory isolation and concurrency
• Operational failure drills
• Live Runtime Canary
• Version-pinned release gates

Next milestone

Cross-Issue Integration Acceptance + Release Gate → v1.0.0

After the remaining integration, fault-injection, canary, and release-validation checks pass, the project can advance to:

v1.0.0 - Production-Oriented Release

Status

Chat Gun remains a production-oriented, pre-production validation project.

v1.0.0-rc.2 is the final planned release candidate before the v1.0 integration and release gates are completed.

v1.0.0-rc.1

v1.0.0-rc.1 - Feature-Complete Release Candidate

This release marks the feature-complete release candidate for Chat Gun's second-stage architecture.

With the Recommendation Framework and Mock Recommendation Adapter now integrated, the project has completed the main Runtime and domain-framework feature path planned before final operational hardening.

Highlights

• Added a generic Recommendation Domain Framework with pluggable domain adapters
• Added DomainRouter for business-neutral recommendation routing
• Added Hard / Soft Constraint evaluation and source-priority handling
• Added BusinessPolicyGate to directly exclude Hard Constraint violations instead of only down-ranking them
• Added clarification flow support for low-confidence recommendation decisions
• Added a generic recommendation card abstraction for domain-specific rendering
• Added a Mock Recommendation Adapter with a PostgreSQL-backed product catalog
• Added Hard Negative cases to verify that semantically similar but business-invalid candidates are rejected
• Added full-chain validation across Domain Routing → Intent → Constraint Evaluation → Policy Gate → Card generation
• Preserved the existing Runtime governance boundaries for authorization, side-effect execution, audit, tracing, and interaction handling

Recommendation Framework

The Recommendation Framework is intentionally business-neutral.

Domain-specific logic is injected through the RecommendationDomainAdapter contract rather than being embedded into the core runtime.

The current validation workload uses a minimal Mock Domain with:

• category
• color
• price

This keeps the framework testable without coupling the core implementation to a real business domain.

Related Pull Requests

• #81
• #83
• #85
• #87

Issues Fixed

• #78

Hard Negative Validation

This release introduces explicit Hard Negative coverage for recommendation safety.

For example, when a user requires:

category = X

a candidate with a similar color but:

category = Y

must be rejected with a Hard Constraint conflict instead of being retained simply because it is semantically similar.

This validates the core design principle:

Vector similarity may retrieve candidates, but business constraints decide whether they are eligible for recommendation.

Release status

v1.0.0-rc.1 represents the point where the planned Runtime and Recommendation feature path is feature complete.

The remaining work before the final v1.0.0 release is focused on post-feature operational hardening rather than adding new core product capabilities.

The next release candidate will focus on:

• Scope-aware and versioned long-term memory governance
• Runtime operations and SLOs
• Worker recovery and stuck-run handling
• Graceful deployment drain
• Execution Manifest and resume compatibility
• Live Runtime Canary validation
• Version-pinned evaluation and release gates

Next milestone

Post-X10 hardening → v1.0.0-rc.2

After the remaining operational hardening and integration acceptance gates pass, the project can advance to:

v1.0.0 - Production-Oriented Release

Status

Chat Gun remains a production-oriented, pre-production validation project.

v1.0.0-rc.1 is a pre-release and should not yet be treated as the final production release.

v0.9.0-alpha.2

v0.9.0-alpha.2 - Identity & Permission Governance

This release advances Chat Gun's runtime hardening work with a trusted identity and authorization boundary for protected Agent operations.

Highlights

• Added trusted Principal / Tenant / Scope context for runtime authorization
• Introduced normalized ResourceRef objects for protected resources
• Added resource-level authorization decisions and permission grants
• Enforced cross-tenant and cross-scope access boundaries
• Added non-transitive delegation controls
• Integrated Tool risk classification with HITL confirmation
• Persisted permission decisions and grants for auditability
• Prevented Agent-callable self-elevation, impersonation, and self-approval paths
• Correlated authorization decisions with durable ToolExecution records and audit events

Related Pull Requests

• #76 - Add agent interaction runtime

Issues Fixed

• #71
• #72
• #74
• #77

Runtime hardening status

This release completes the identity and permission governance layer on top of the existing side-effect execution runtime.

The next beta milestone focuses on:

• Business Interaction Runtime for concurrent input, cancellation, superseding, and active-run ownership
• Decision Provenance and Context Reference primitives

These capabilities will complete the current pre-recommendation runtime hardening gate before the project moves into the recommendation framework phase.

Status

Chat Gun remains a production-oriented, pre-production validation project.

v0.9.0-alpha.2 is a pre-release and does not yet represent the v1.0 operational release gate.

v0.9.0-alpha.1

v0.9.0-alpha.1 - Runtime Hardening Alpha

This alpha release marks the first public milestone of Chat Gun's second-stage runtime hardening work.

Highlights

• Durable Task / Step runtime and PostgreSQL persistence
• Retry budgets, idempotency, persistent audit, compensation, and distributed locking
• Redis-backed rate limiting and context budget governance
• OpenTelemetry tracing, runtime metrics, model fallback, and cost tracking
• Opik-based tracing and evaluation workflow
• Durable side-effect ToolExecution ledger with replay protection and reconciliation
• Trusted principal, scope, resource-level authorization, and permission governance

Runtime hardening status

This release completes the current side-effect safety and authorization foundation.

The next beta milestone will add:

• Concurrent user-input and active-run ownership governance
• Cancellation, superseding, and clarification-resume policies
• Structured decision provenance and context/evidence references

Once those runtime hardening capabilities are complete, the project will move to:

v0.9.0-beta.1 - Production-Hardened Runtime Beta

Roadmap tracking

See the corresponding GitHub PR for implementation details and acceptance criteria:

#68 - Update Readme Bff Info
#66 - Add Runtime Identity Permission Governance
#65 - Add Side Effect Tool Execution Runtime
#57 - Update Readme And All Feature Docs
#56 - Integrate Opik Agent Tracing Evaluation
#52 - Add Observability Metrics Tracing
#50 - Add Context Budget Governance
#48 - Add Redis Rate Limit
#42 - Add Agent Compensation Runtime-phase2
#38 - Add Agent Compensation Runtime-phase1
#35 - Add Agent Idempotency Audit
#34 - Add Agent Retry Budget
#32 - Second Stage / Add Agent Task State Machine

Chat Gun remains a production-oriented, pre-production validation project.
It has not yet reached the v1.0 operational and release-validation gates.