Conversation
Vercel deployment acceptance is not terminal success. Declare non-terminal deployments as durable async operations, poll the exact deployment ID through the existing Runtime, and settle only on authoritative terminal provider states. The accompanying Spec Kit artifacts preserve the decision and regression contract. Constraint: Reuse the existing Runtime scheduler and settlement path without generic Runtime changes Rejected: Treat accepted or BUILDING deployments as success | loses the authoritative provider result Rejected: Poll deployment lists | cannot prove which deployment owns the operation Confidence: high Scope-risk: narrow Reversibility: clean Directive: Do not reclassify Vercel acceptance as terminal success or replay launch writes from poll continuations Tested: 102 scoped Vercel and Runtime tests; 172 deploy and Tool contract regression tests; scoped Ruff critical rules Not-tested: Live Vercel deployment and long-duration retry termination policy
Tenant and Agent timezone values now enter the scheduler through one IANA validation boundary, while new tenants receive the confirmed Beijing default. Constraint: Agent timezone remains nullable to preserve tenant inheritance. Rejected: Validate against COMMON_TIMEZONES | it is a UI shortlist, not the complete IANA set. Confidence: high Scope-risk: narrow Directive: Do not reintroduce silent UTC fallback for configured Trigger timezones. Tested: backend/tests/test_timezone_validation.py (14 passed); Alembic single-head check. Not-tested: Migration execution against a production-sized tenants table.
The evaluator now owns Cron occurrence calculation in the Agent effective timezone. The daemon, dispatch key, queue record, and Runtime source all consume that same planned instant, with a bounded 30-second grace and creation-time lower bound. Constraint: Keep cooldown_seconds and non-Cron Trigger behavior compatible. Rejected: Persist next_run_at or schedule_effective_from | the accepted design uses current rules plus a bounded grace without new schedule state. Confidence: high Scope-risk: moderate Directive: Do not derive Cron occurrences from last_fired_at or recompute them below evaluator. Tested: 22 scheduling, queue, intake, completion, and A2A tests; scoped Ruff. Not-tested: DST edge behavior and second-level Cron expressions are out of scope.
Scheduled Trigger intake failures now roll back the occurrence instead of persisting a failed receipt that blocks the next daemon scan. Structured logs retain the failure evidence, while webhook receipts preserve their existing synchronous failure contract. Constraint: Retry is only the ordinary 15-second scan while the occurrence remains inside the 30-second grace. Rejected: Add retry counters, backoff jobs, or new schedule fields | outside the confirmed minimal repair. Confidence: high Scope-risk: narrow Directive: A failed scheduled intake must not consume its occurrence identity. Tested: 40 timezone, scheduling, queue, Runtime, A2A, and webhook tests; scoped Ruff. Not-tested: Process termination during the database commit syscall.
Cron creation already rejected malformed expressions, but both existing update boundaries could persist them. Validate before mutation and commit while preserving REST replacement and Agent-tool patch semantics. Constraint: Preserve current Trigger APIs and config compatibility Rejected: Introduce a shared Trigger config abstraction | interface unification remains deferred Confidence: high Scope-risk: narrow Reversibility: clean Directive: Trigger config timezone may remain stored for compatibility but must not define occurrence timezone Tested: Full backend pytest 2162 passed; focused Trigger tests 18 passed; scoped Ruff and git diff checks passed Not-tested: DST-specific and second-level Cron behavior remain out of scope
The scheduler already falls back through Agent and Tenant to Asia/Shanghai, but the Agent detail response still advertised UTC when both stored values were absent. Reuse the platform default so the visible configuration describes the runtime behavior. Constraint: Preserve the existing Agent detail response shape Rejected: Add a new frontend timezone resolution path | the backend already owns effective timezone resolution Confidence: high Scope-risk: narrow Reversibility: clean Directive: Any displayed effective timezone must follow the same Agent to Tenant to platform-default order as scheduling Tested: Full backend pytest 2163 passed; timezone tests 15 passed; scoped Ruff and git diff checks passed Not-tested: Frontend visual regression was unnecessary because the response field shape is unchanged
Current main routes Trigger persistence through query_dao and has advanced the Alembic chain. Preserve those boundaries while replaying the scheduling repair, move Cron imports to the module boundary, and adapt tests to the DAO session contract. Constraint: Publish without rebasing the user's dirty working tree Constraint: New migrations must follow the current single-head and DDL-only rules Rejected: Rebase the checked-out fix branch | unrelated concurrent work makes worktree mutation unsafe Confidence: high Scope-risk: narrow Reversibility: clean Directive: Keep the PR branch based on current upstream main and retain query_dao session ownership Tested: Focused timezone and Trigger regression 33 passed; scoped Ruff passed; Alembic reports one f061 head Not-tested: Full backend suite was interrupted before completion
Persist tenant-scoped bootstrap identity so Morty and Meeseeks are initialized once, while surviving Agent storage remains repairable. Existing deployments lazily backfill stable IDs from the legacy marker or historical rows. Constraint: Existing deployments have no database bootstrap marker and docs are ignored by default. Rejected: Restore the legacy marker early return | it would disable storage drift repair and remains unsafe when storage changes. Confidence: high Scope-risk: moderate Reversibility: clean Directive: Do not use Agent name or runtime status as the default-Agent initialization fact. Tested: 38 scoped pytest cases; Ruff; git diff --check. Not-tested: Real PostgreSQL container startup because the local Docker daemon is unavailable.
The mention picker stopped at eight results and keyboard navigation could move the active candidate outside the visible popup. Keep all filtered members in the bounded list and synchronize its local scroll position with the highlighted option. Constraint: Preserve existing structured mention identity and IME behavior. Rejected: Keep the eight-candidate cap | members beyond the cap would remain unreachable by scrolling. Confidence: high Scope-risk: narrow Reversibility: clean Directive: Keep keyboard highlight changes synchronized with the mention popup scroll position. Tested: Frontend npm test (89 passed); npm run build; Playwright with 12 mocked members, mouse wheel and keyboard scrolling. Not-tested: Live backend WebSocket behavior; unrelated to the local candidate picker.
Bring Draft PR #827 into the local validation branch so its exact provider-settlement path can be tested with the other release candidates. Constraint: Preserve the Draft PR head unchanged inside the merge. Confidence: high Scope-risk: moderate Reversibility: clean Related: #827 Tested: Merge completed without conflicts. Not-tested: Combined branch tests run after all Draft PRs are assembled.
Bring Draft PR #833 into the local validation branch alongside the Vercel settlement repair, preserving both Tool surfaces for combined testing. Constraint: Resolve overlapping agent_tools changes without dropping either Draft PR contract. Confidence: medium Scope-risk: broad Reversibility: clean Related: #833 Tested: Combined tests run after conflict resolution and remaining Draft PR merges. Not-tested: Merge compatibility until conflicts are resolved. # Conflicts: # backend/app/schemas/schemas.py
Bring Draft PR #837 into the local validation branch so bootstrap identity and storage repair behavior can be tested with the other release candidates. Constraint: Preserve the Draft PR head unchanged inside the merge. Confidence: high Scope-risk: moderate Reversibility: clean Related: #837 Tested: Merge completed without conflicts. Not-tested: Combined branch tests run after all Draft PRs are assembled.
Bring Draft PR #927 into the local validation branch so the complete mention picker is included in the release-candidate frontend test pass. Constraint: Preserve structured mention identity and existing IME behavior. Confidence: high Scope-risk: narrow Reversibility: clean Related: #927 Tested: Merge completed without conflicts. Not-tested: Combined branch tests run after all Draft PRs are assembled.
Direct Chat kept both per-session runtime caches and component-wide active state. Project controls through the selected session identity and keep delayed background sends from mutating the visible conversation. Constraint: Preserve background Session execution and WebSocket delivery Rejected: Close the previous Session socket on navigation | long-running Sessions must continue after the user switches away Confidence: high Scope-risk: narrow Reversibility: clean Directive: Never let background Session events update the visible composer without matching Agent and Session identities Tested: Frontend node tests 90 passed; TypeScript and Vite production build passed Not-tested: Live backend-connected multi-Session browser flow
Merge the latest authenticated channel, browser-bound SSO, and image timeout reconciliation fixes from main while preserving the accumulated release candidate repairs. Constraint: Preserve the existing v1.11.4 candidate commit history Rejected: Rebase the release candidate | rewriting the accumulated candidate history would weaken the release audit trail Confidence: high Scope-risk: moderate Reversibility: clean Directive: Re-run release candidate regressions whenever main advances again Tested: 75 focused backend tests passed; frontend node tests 91 passed; TypeScript and Vite production build passed Not-tested: Full backend suite, Docker upgrade paths, or live provider and browser flows
Record the current main baseline, Direct Chat Session isolation scenarios, and the newly merged OAuth, channel authentication, and image timeout reconciliation paths in one executable release-candidate checklist. Constraint: Historical PR evidence cannot replace candidate or live validation Rejected: Keep the previous four-feature checklist | it would omit the latest main security and reconciliation changes Confidence: high Scope-risk: narrow Reversibility: clean Directive: Refresh the baseline SHA, candidate evidence, and affected cases whenever main advances Tested: Markdown structure, referenced paths, 75 focused backend tests, 91 frontend tests, and production frontend build Not-tested: Full backend suite, Docker upgrade paths, and live provider or browser cases
Record the two active Alembic heads and Drone fresh-database duplicate-column failure so the synchronized release candidate cannot be treated as publishable until the main migration graph is repaired and revalidated. Constraint: The Direct Chat PR changes only frontend files and must not absorb an unrelated migration repair Rejected: Ignore the failed check as unrelated | v1.11.4 now contains the same main migration state Confidence: high Scope-risk: narrow Reversibility: clean Directive: Clear this blocker only with fresh and upgrade database evidence on the repaired candidate Tested: Alembic heads inspected; Drone build 486 clone, image build, and migration logs read Not-tested: Repaired fresh or upgrade database path because no repair is present yet
Freeze the model-visible Workset and accepted execution binding in checkpoint state, separate Provider correlation from Runtime identity, and give repairable failures a sanitized model-visible result. Add independent 10/20 repair budgets, operation-specific deadline/cancel/lease controls, and an incremental RegisteredTool compatibility boundary. Constraint: Existing checkpoints and nullable Receipt rows must remain recoverable during mixed-version rollout Rejected: Re-resolve enabled assignments in Tool Step | changes an already accepted model decision Rejected: Reuse Provider-local call IDs as Runtime identity | IDs repeat across Assistant turns Confidence: high Scope-risk: broad Reversibility: clean Directive: Do not remove the legacy resolver until its zero-usage release and rollback-window gate is satisfied Tested: 834 Runtime/Tool pytest cases; 9 migration/contract cases; Alembic f061-f062 offline upgrade and downgrade; scoped Ruff; Architecture Guard; git diff check Not-tested: Live Provider credentials and online migration against an isolated PostgreSQL database
Integrate the checkpoint-stable Tool Runtime repair while preserving the release branch's established SpecKit constitution and trigger fixes. Join the release timezone migration and main-based Tool identity migration with a no-op Alembic merge revision. Constraint: v1.11.4 already carries a sibling f061 timezone migration that is absent from upstream main Rejected: Retarget the feature migration to the release-only head | would make PR #945 diverge from main migration history Rejected: Leave two Alembic heads | release startup and migration gates require one head Confidence: high Scope-risk: broad Reversibility: clean Directive: Keep f063_merge_v1_11_4_heads when rebasing or publishing the release candidate Tested: v1.11.4 import path verified; 834 Runtime/Tool pytest cases; 5 release migration cases; single Alembic head; fatal Ruff; Architecture Guard; git diff check Not-tested: Live Provider credentials and online migration against an isolated PostgreSQL database
Drone clones only the target repository before checking out the fork PR SHA. Publish this no-op descendant to both repositories so the synchronize build can resolve the commit without changing the reviewed tree. Constraint: Drone build 487 failed in clone before any test because the fork-only SHA was absent from dataelement/Clawith Rejected: Ignore the failed required check | would leave PR health ambiguous Confidence: high Scope-risk: narrow Reversibility: clean Directive: This empty commit carries no release behavior and need not be merged separately into v1.11.4 Tested: Underlying tree is identical to 1dbad6d Not-tested: Drone rerun until remote status is observed
Fresh installs create the enterprise_info target shape from current ORM metadata before Alembic replays f061. Inspecting the live schema keeps that replay idempotent while preserving the legacy upgrade path, and the unified-schema assertion now leaves f062-owned Tool identity columns to their dedicated migration contract. Constraint: Fresh bootstrap derives tables from current ORM metadata before replaying historical revisions Rejected: Skip the failing CI migration lane | would leave a documented v1.11.4 P0 release blocker unresolved Confidence: high Scope-risk: narrow Directive: Keep provider_call_id and contract_version owned by f062 rather than backporting them into the unified baseline revision Tested: 836 Runtime, Tool, and migration tests; scoped Ruff; py_compile Not-tested: Fresh PostgreSQL bootstrap locally because Docker is unavailable; Drone will provide that evidence
Merge the CI-proven f061 idempotence repair into the release candidate while retaining the release-only f063 revision that joins the timezone and Tool Runtime migration chains. The regression record now distinguishes the passing fresh path from the still-unverified v1.11.3 upgrade path. Constraint: v1.11.4 must retain one Alembic head across both release migration branches Rejected: Mark the entire database P0 complete | the previous-version upgrade path still lacks real database evidence Confidence: high Scope-risk: moderate Directive: Do not remove f063 or mark A4 passed until a v1.11.3 database snapshot upgrades successfully Tested: 836 Runtime, Tool, and migration tests; scoped Ruff; Alembic single-head check; Architecture Guard P0; Drone #489 fresh PostgreSQL migration Not-tested: Upgrade from a populated v1.11.3 database snapshot
Native group replies already persist human mentions without dispatching work, but the Runtime at preflight rejected every non-Agent participant. Split public mention validation from Agent handoff validation so mixed human and Agent targets remain atomic while child Runs are created only for wakeable Agents. Constraint: Human mentions must remain visible without creating child Runs. Rejected: Strip human IDs during model repair | loses structured mention metadata and contradicts group message behavior. Confidence: high Scope-risk: narrow Directive: Keep public mention targets distinct from wakeable Agent targets. Tested: 232 scoped Runtime and group delivery tests; Ruff check on changed files. Not-tested: Browser rendering and live 3010 mixed-mention E2E pending deployment.
Merge the standalone main-based mention repair into the release candidate so mixed human and Agent targets preserve public message metadata while only wakeable Agents receive child Runs. The automatic merge retains the Tool Runtime contract work already integrated into model_step_service. Constraint: Human participants are valid visible mention targets but are never Runtime handoff targets Rejected: Continue carrying the fix only on the Feishu reimbursement branch | obscures ownership and release ancestry Confidence: high Scope-risk: moderate Directive: Keep visible mention validation separate from wakeable Agent handoff validation Tested: 867 Runtime, Tool, finish-protocol, and migration tests; fatal Ruff; Architecture Guard P0; Alembic single-head check Not-tested: Live mixed-mention E2E on deployed port 3010
Add typed Feishu approval definition, attachment upload, and create tools while binding provider submission to the exact tenant, Run, Tool Ledger receipt, applicant, and in-chat confirmation. Constraint: Approval creation must not depend on a new frontend or legacy ApprovalRequest flow Constraint: Existing user worktree changes remain outside this commit Rejected: Bare yes/no confirmation | stale replies could authorize another request Rejected: Raw approver and CC open IDs | bypasses tenant roster authorization Rejected: Reusable bearer proof | could replay an identical provider write Confidence: high Scope-risk: moderate Reversibility: clean Directive: Do not expose feishu_approval_create outside the receipt-bound Durable Runtime conversation gate Tested: 335 relevant backend tests; scoped Ruff; compileall; diff check; independent code review and verification Not-tested: Live Feishu Provider create and 3010 deployment
Preserve a bounded, sanitized Provider receipt in the Tool outcome and surface HTTP status, business code, message, and response body to the model. Approval reads and writes retain their existing retry classification, while attachment inputs are rejected before confirmation unless they contain stable file-code strings. Constraint: External approval writes must never be replayed after an ambiguous Provider outcome Constraint: Provider response metadata must pass through the Tool Ledger sanitizer before model visibility Rejected: Return only a generic rejection string | leaves the model unable to repair invalid form controls or permissions Rejected: Accept attachment objects in form_data | confirmation would bind an unstable provider payload shape Confidence: high Scope-risk: moderate Directive: Preserve provider receipt bounds and redaction whenever adding new Feishu failure fields Tested: 804 Runtime and Tool tests; 201 approval-focused tests; fatal Ruff; Architecture Guard P0; diff check Not-tested: Live Feishu Provider create and deployed 3010 approval flow
Merge the standalone Feishu approval tools into the release Runtime while retaining stable Tool Call identity, validation, deadlines, cancellation, lease renewal, and repair budgeting. Approval creation now issues its single-use authorization inside the controlled application execution path, after the exact call has been confirmed and reserved. Constraint: Approval writes must remain bound to the tenant, actor, Run, call instance, execution receipt, lease owner, and exact arguments Rejected: Restore the approval branch's direct executor call | would bypass v1.11.4 deadline, cancellation, lease, and Tool contract controls Confidence: high Scope-risk: broad Directive: Keep approval authorization issuance inside _execute_application_with_controls and preserve call_instance_id as the Runtime identity Tested: 941 Runtime, Tool, approval, finish-protocol, and migration tests; fatal Ruff; Architecture Guard P0; Alembic single-head check Not-tested: Live Feishu approval creation and deployed 3010 confirmation flow
Set the existing protocol repair, safe-read replay, and model-visible Tool episode limits to ten while preserving their current independent state and execution semantics. Update focused tests and planning artifacts to make the off-by-one behavior explicit. Constraint: Tool-related retry and repair limits must be ten without restructuring the existing counters Rejected: Unify protocol, Receipt, and model-visible repair state now | counter redesign is intentionally deferred Confidence: high Scope-risk: moderate Directive: Keep the independent counters until the planned repair-control refactor; do not infer identical attempt semantics from the shared numeric limit Tested: 911 Runtime and Tool pytest cases; scoped Ruff; fatal-level caller Ruff; py_compile; git diff --check Not-tested: Live Provider credentials
Merge the main-based Tool Runtime follow-up so the release candidate uses ten for protocol repair, safe-read replay, and model-visible Tool episode limits without restructuring their independent counters. Constraint: v1.11.4 must remain aligned with PR 945 while retaining its release-only approval and mention fixes Rejected: Cherry-pick individual files | merging the reviewed main-based commit preserves its tests and planning evidence Confidence: high Scope-risk: moderate Directive: Keep protocol, Receipt, and model-visible repair state separate until the planned counter refactor Tested: 928 release-combination pytest cases with release PYTHONPATH; scoped Ruff; fatal-level caller Ruff; py_compile; staged diff check Not-tested: Live Provider credentials
Gemini reuses provider call identifiers across assistant turns, so a history-wide lookup allowed later calls to overwrite earlier tool names. Scope name resolution to the active assistant exchange while preserving provider wire identifiers. Constraint: Gemini provider call IDs are not globally unique across turns Rejected: Persist globally unique provider IDs | would alter provider wire identity and conflict with existing Runtime correlation Confidence: high Scope-risk: narrow Directive: Keep Tool Result name resolution exchange-local when modifying Gemini history lowering Tested: backend/tests/test_llm_single_step.py; LLM scoped tests; Ruff Not-tested: Live Gemini API
Unknown dynamic MCP receipts now use the existing audited Direct Chat reconciliation flow. A user must confirm whether the external action happened before the old receipt is settled and the Run may resume; the Runtime never replays the original MCP call automatically. Constraint: Dynamic MCP Tools are conservatively classified external_write with retry policy never. Rejected: Automatically retry an unknown MCP call | could duplicate an external side effect. Rejected: Add a separate MCP reconciler service | unnecessary while explicit human confirmation provides a real recovery outlet. Confidence: high Scope-risk: narrow Directive: Do not make unknown MCP receipts retryable without an explicit idempotency contract. Tested: 47 Tool ledger and Direct Chat runtime-state tests; 17 targeted unknown/reconciliation tests; scoped Ruff; git diff --check. Not-tested: Browser UI interaction and a live MCP server with an ambiguous transport outcome.
The integrated Tool fixes expose two stale assertions in the release test suite: network reads now use the declared 60-second Runtime budget, and the durable execution model already includes provider identity and contract version columns. Align those assertions and remove a duplicate import so the combined release branch can be verified as one unit. Constraint: Preserve the eight reviewed fix commits without folding or rewriting their history Rejected: Ignore the full-suite failures | they would leave the integration PR without a clean release-level regression result Confidence: high Scope-risk: narrow Reversibility: clean Directive: Keep deadline and schema assertions synchronized with the production Tool contract Tested: Full backend suite, 2357 passed; scoped Ruff excluding pre-existing agent_tools.py debt; git diff --check Not-tested: Live external MCP provider execution
Some model providers reject composite Tool schemas before execution, while generic Feishu approval failures hide the receipt needed to correct a request. Keep model-visible schemas provider-compatible, enforce composite constraints in handlers, and preserve bounded sanitized Feishu receipts through Runtime outcome storage. Constraint: Model-visible Tool schemas must avoid anyOf, oneOf, and allOf for provider compatibility Rejected: Drop conditional argument constraints | handlers still need to reject invalid calls Rejected: Persist raw provider responses without bounds | response bodies may be large or contain secrets Confidence: high Scope-risk: moderate Directive: Keep composite constraints in handlers when simplifying model-visible schemas Tested: 290 scoped pytest cases passed; Ruff passed on 11 files and the changed agent_tools.py regions had no reported violations Not-tested: Live Feishu approval calls and external model-provider acceptance
The Tool follow-up suite expected composite constraints in builtin schemas, while the provider-compatibility repair intentionally delegates those cross-field rules to handlers. Keep scalar schema validation coverage here and rely on the existing handler regressions for upload and deployment alternatives. Constraint: Model-visible builtin schemas must avoid provider-rejected anyOf, oneOf, and allOf Rejected: Restore composite builtin schemas | recreates provider 400 failures before Tool execution Confidence: high Scope-risk: narrow Directive: Test cross-field builtin constraints at the handler boundary when provider-visible schemas cannot express them safely Tested: 185 scoped tests passed; Ruff passed for the adjusted validation test Not-tested: Live provider schema acceptance
The release branch had integrated the v1.11.4 repair set while both product version files still reported v1.11.3. Align backend and frontend version identity so the 3010 deployment and regression evidence can be attributed to the correct candidate. Constraint: Backend and frontend must report one release-candidate version Confidence: high Scope-risk: narrow Directive: Keep both VERSION files synchronized for release candidates Tested: Backend 2356 tests; frontend 91 tests; frontend production build; scoped Ruff; Alembic single head; Arch-Guard P0 Not-tested: 3010 deployment and live regression
The v1.11.4 Runtime resolves dynamic MCP tools through durable execution bindings, while the sandbox PR test still mocked the retired name-only helper. Point the test at the binding resolver without weakening either contract.\n\nConstraint: Preserve v1.11.4 Tool execution binding semantics while integrating PR #961.\nRejected: Restore the name-only MCP helper | duplicates routing state and weakens execution integrity.\nConfidence: high\nScope-risk: narrow\nDirective: Sandbox tests must mock the same binding boundary used by Runtime execution.\nTested: 59 scoped sandbox, Tool validation, and builtin contract tests passed.\nNot-tested: Full backend suite at commit time.
PR #961 adds one execute_code policy lookup and publication metadata to every sandbox dispatch. Update existing mocks and catalog assertions to model those now-required inputs while preserving the no-reexecution outcome contract.\n\nConstraint: Integrate isolated Session output without weakening existing AgentBay readiness or unknown-execution safety.\nRejected: Hide the execute_code policy lookup in production | would make model guidance diverge from the active sandbox policy.\nConfidence: high\nScope-risk: narrow\nDirective: Sandbox backend mocks must expose the active workspace and publication contract.\nTested: Three previously failing integration tests passed.\nNot-tested: Full backend suite at commit time.
Native group Sessions are intentionally shared and therefore have no owning Agent. Authorize their sandbox scope through the active tenant Group and active Agent participant membership while preserving exact ownership for Direct and external-channel Sessions. Constraint: Native group Sessions intentionally have chat_sessions.agent_id NULL Rejected: Backfill a group Session Agent | shared Sessions can host multiple Agents Rejected: Allow every group Session | would bypass tenant Group and active membership checks Confidence: high Scope-risk: narrow Reversibility: clean Directive: Keep Direct and external-group exact Agent ownership checks intact Tested: 155 scoped DAO, group chat, Runtime, Sandbox, subprocess, and workspace tests Tested: Ruff passed for changed DAO and policy test files Not-tested: 3010 live group execution before deployment
…ion-scope fix(runtime): authorize native group sandbox execution
A depleted Tool repair budget previously parked the Run in waiting_user, leaving users with an apparently active task and only a plain assistant message. Treat the exhausted budget as a structured terminal failure so the existing run_failed delivery and frontend error paths are used. Constraint: Historical waiting_user checkpoints for repair exhaustion must remain resumable. Rejected: Add a special frontend waiting card | the exhausted repair budget is not recoverable without starting a new turn and should release the Run lane. Confidence: high Scope-risk: narrow Directive: Keep repair-budget exhaustion terminal unless a bounded automatic recovery mechanism is introduced. Tested: 62 Runtime node, checkpoint, chat stream, and repair budget tests; scoped Ruff; git diff --check. Not-tested: Live WebSocket rendering against the deployed frontend.
Fail runs when tool repair budget is exhausted
Replace the product-style base prompt with a concise execution contract and add an independent semantic completion gate after deterministic Tool ledger verification. Explicit repair decisions re-enter the Agent loop up to ten times; gate infrastructure failures fail open, and exhausted semantic repairs deliver the latest candidate with internal diagnostics. Constraint: Completion checking must not suppress a usable model answer when the judge is unavailable or repeatedly disagrees. Rejected: Treat semantic judge failures like Tool ledger failures | semantic evaluation is probabilistic and must not block normal output. Confidence: high Scope-risk: moderate Directive: Keep Tool ledger verification fail-closed and semantic completion infrastructure fail-open. Tested: 78 scoped backend tests; scoped Ruff; git diff --check Not-tested: Live provider completion-gate call and 3010 end-to-end Run
Add evidence-based task completion gate
Tool-call chat rows written after the tenant backfill omitted tenant ownership, so request-scoped ORM filtering hid them from session history even though execution data remained in PostgreSQL. Resolve the Agent tenant on write and repair existing null-owned tool rows by Agent or Session ownership. Constraint: ChatMessage is globally tenant-scoped and nullable legacy rows are intentionally invisible in request context. Rejected: Bypass tenant filtering in the history endpoint | would weaken cross-tenant isolation. Confidence: high Scope-risk: narrow Directive: Every new ChatMessage writer must persist tenant_id before commit. Tested: 24 chat session service/API tests; scoped Ruff; live DB/API diagnosis on 3010. Not-tested: Browser rendering until the updated backend is deployed.
(cherry picked from commit 266b410)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed
This release-candidate branch integrates and validates the currently planned v1.11.4 repairs against main:
Why
These changes assemble the pending Runtime, scheduling, Agent lifecycle, chat isolation, mention, and migration repairs into one branch so their interactions can be reviewed and validated as a release candidate instead of relying on isolated PR evidence.
Impact
The branch changes backend Runtime and Tool execution behavior, Trigger scheduling semantics, default Agent bootstrap behavior, group and Direct Chat UI behavior, and the Alembic migration graph. It intentionally keeps existing public APIs and reuses the current Runtime scheduling and settlement paths.
Validation recorded on this branch
Remaining release gates
See V1.11.4_REGRESSION_TEST_CASES.md for the detailed release matrix.