Support procedures and resolution

​

Goal

Inspect the initial resolution contracts without confusing available configuration with verified customer outcomes.

​

Prerequisites

• Matching unreleased Support API. Sequence 1 adds no migration or environment setting.
• The sequence 2 workflow foundation requires migration 000561_support_workflow_outcomes before the matching API and worker; quiesce old workflow workers during replacement.
• Current staff session, configuration and conversation-read permissions, and an environment belonging to the requested workspace.
• Authoring requires migrations 000562_support_procedure_versions and 000563_support_procedure_generation after 000561; replace quiesced API/workflow/AI workers together.

​

Workflow

​

Support-to-engineering handoffs

Local, unreleased sequence 6 uses existing platform objectives, isolated engineering workspaces, repository operations and browser journeys. In Integrations, an owner/admin explicitly binds one Support workspace/environment/inbox to a project they can currently administer. The binding expires within 30 days, remains valid across sign-out, and is separately revocable. Revoke an old binding before authorizing its replacement. Support authority never grants platform project access by itself. Take over the case, then open Engineering handoff in its existing AI controls. Select an authorized project, a separately configured preview debug-agent policy, a completed failed preview verification run from the past 24 hours, and a bounded budget. Explicitly attest that reproduction uses isolated, redacted test data. Handoffs expire within 24 hours and within both case retention and project binding expiry. Only one immutable handoff request is accepted per case; retries recover the same objective. A changed request requires a new resolution case. The diagnostic package contains pinned project/application/source/journey identifiers, failure state and case-scoped action receipt categories. A dedicated resource-context read exposes structural reproduction steps and failed assertions, omitting free text, selector values, paths, input values, credentials, fixture contents, raw logs and browser artifacts. If redaction prevents reproduction, the engineer must request consultation. No private notes or customer messages become agent instructions. Repository content and diagnostic output remain untrusted evidence. The existing agent scheduler owns execution; Support’s maintenance worker recovers objective admission and cancels expired/revoked handoffs. Before reasoning and each tool dispatch, current workspace, organizational membership, project authority, binding revision/expiry, case ownership and exact objective/project/policy are rechecked. The Support marker is server-only. Source materialization and PR base commits are constrained to the original pinned reproduction revision; changed source requires a new reviewed case. Allowed work is preview engineering, scoped repository inspection and safe project status. No merge, deployment, secrets, database administration, delegation or criterion/authority mutation is granted. The agent may create a draft PR. Pin its current head through the handoff overlay: the server checks its bound engineering operation/branch, draft status, current controller PR-operation evidence, fresh named functional-test evidence matching the complete PR source, and a successful verification-only build for that head. The objective requires this verified draft PR before completion. Human merge and deployment approvals happen separately in the project. Run the original unchanged journey against the actual deployed merge revision, with parent_run_id equal to the failed preview run. The handoff verifier re-reads the PR and journey, rejects changed heads/definitions/targets and requires current passing production evidence. It records engineering verification and a localized customer update; it does not close the case. Resume the original procedure only when appropriate so its business verifier establishes resolution. Customer case APIs add optional engineering_status with an allowlisted state only. The narrowly integrated customer display uses existing case panels and English/French/Pidgin copy; Gemini owns the concurrent customer UI rebuild. No project identifiers, repository details or internal evidence are exposed in this projection. API additions: /ai/engineering-bindings GET/POST, /{bindingID}/revoke; /cases/{caseID}/engineering GET/POST, /pull-request, /verify, /cancel. Creation uses the case revision; subsequent handoff mutations use its revision in If-Match. Binding creation uses a stable caller-generated UUID for recovery; handoff creation uses a server-derived durable objective identity. Listing bindings uses the existing cursor pattern and returns only the authorizing operator’s bindings. Apply Support migration 575 after the complete current migration head, including concurrent platform migration 574. Support migrations are 561–573 and 575; do not rename or skip the platform migration in production. Quiesce older workflow, connector and AI workers, apply migrations, then start matching API/agent/Support workers before enabling new admissions. No setting is enabled automatically and no new blanket qualification lock exists. For rollback, pause procedures and revoke action/project grants, settle or explicitly cancel in-flight work with the matching worker, and retain additive evidence tables. The down migration refuses retained bindings/handoffs. Customer erasure scrubs case diagnostic evidence and cancels its engineering thread; the bridge never copies customer payloads into durable platform records. Focused offline tests and browser fixtures do not establish a synthetic issue’s real GitHub/build/deployment journey. PostgreSQL concurrency/restart/migration tests, live provider/language evaluation and previously blocked device qualification remain explicitly unverified until executed. No production deployment, real PR or external mutation was performed during implementation.

​

Reviewed improvements, shadow tests and rollout

The unreleased AI interface keeps Procedures, Procedure outcomes, Improvements and Evaluations directly accessible on desktop, with other views in More. Narrow screens use the AI views selector. Procedure outcomes groups primary metrics, resolution evidence, human oversight and cost coverage; each rate names its denominator, and unavailable values remain explicit. Refresh advances the last-30-day window. Evaluations separates Runs, Datasets and Procedure tests. Add examples opens the reviewed regression import dialog; offline test setup preserves the exact procedure version, dataset, baseline and environment. English, French and Pidgin controls, recovery states and keyboard navigation are included. No migration or permission change is required for this interface update. Unreleased sequence 5 requires migrations 572–573 after 561–571. AI Improvements generates unpublished proposals from authorized retained sources. Inspect and accept the exact candidate; publication stays a separate human action. Private notes and customer identities are not generation sources. Evaluations → Procedure tests saves human-reviewed redacted failure examples from accepted proposals as immutable regressions. Compare versions on the same dataset and baseline, inspecting exact arguments, authorization and verifier receipts. Shadow execution has no live provider, customer message or action transport. Machine assertions and human ratings remain separate. Stage a baseline and percentage in Procedures → Rollout before publishing the candidate through normal review. Stable per-case selection pins ongoing cases. Zero percent returns new cases to baseline. Changed candidate semantics require explicit review and saving the rollout again. Pausing affects new admissions. Procedure outcomes separates verified business results, human escalation ratings, customer confirmation and mature seven-day reopen accounting. AI microcredits use recorded attempts during retained case lifetimes and exclude integration charges; unpriced attempts make cost per verified resolution unavailable. Retention and erasure scrub proposals and regression evidence. New APIs include ai/improvements, ai/improvement-groups, ai/procedure-regressions, ai/procedures/{workflowID}/rollout, ai/procedure-report and cases/{caseID}/escalation-review. Existing evaluation-runs accepts procedure_version_id, procedure_revision, shadow and same-dataset baseline_id. Current source scope and revision checks apply. Quiesce incompatible workers and retain additive evidence tables on rollback. Live PostgreSQL, provider and device qualification is not established by offline checks.

​

Persistent cases and verified continuation

Migrations 567–571 add case ownership, case waits in the existing workflow scheduler, bounded reasoning in existing AI accounting, and case-linked erasure. Quiesce older workers before admitting these executions. Existing versions remain pinned through publication changes; takeover suspends linked effects and expiry hands over with evidence. Staff /cases APIs expose scoped progress, consultation, takeover, resume and cancellation. Control mutations require If-Match. Authenticated widget/native/portal conversation /case APIs return safe status and exact pending operation/arguments; /case/confirmations/{receiptID} accepts only the persisted receipt revision. Financial/security actions retain separate current-session staff approval. Payment repair requires fresh payment_verified and repair_allowed read evidence. Job retry requires current failed status and declared safe retry semantics. Read-back verification is required at completion; a queued retry, successful write response or customer silence is not resolution. Unsolicited customer updates suspend proposals for review. Staff can answer a pending case question through revision-protected consultation-responses without takeover or action approval. External channels receive an authenticated brand/conversation confirmation link only with a safe configured destination and eligible private customer binding; unavailable authentication or failed delivery hands over. Web, portal and four mobile screens expose localized progress and exact confirmations. Case reasoning has no action tools, cannot change authority or completion and persists only a concise internal summary. Customer erasure removes the linked summary. Focused tests and API compilation are not live database, provider, language, browser or device qualification. This implementation is unreleased.

​

Registered actions and execution grants

Approved stackshift.support.app/v2 manifests register fixed HTTPS actions, flat typed inputs, safe outputs, server-bound identity and risk. Writes require idempotency, reconciliation and a registered read verifier. Explicit action_operations consent returns a separate action_key_id/action_secret once. Existing v1 installations receive no automatic authority. Developer Applications now provides approved version selection and explicit permission/action consent. Installation and upgrade accept a stable Idempotency-Key, recovering encrypted credentials for 24 hours for the same current authorized membership. The browser stores only the consent request and key. Upgrades rotate credentials, revoke grants and disable policies for renewed review. Expired recovery keys cannot create another installation. Integration controls list consented actions and revision-protected policies. Automatic bounded writes require enforced input limits; financial/security actions require independent staff approval. Optional execution grants explicitly authorize selected operations for at most 90 days across staff sign-out. Revocation, changed installation, workspace suspension or lost authorizing membership blocks dispatch; human approvals retain live-session checks. PUT /api/v1/support/machine/customer-links uses the explicit v2 customer-links:write permission and If-Match to verify, replace or revoke a scoped customer mapping. Customer text and action arguments cannot select another identity. Changing a mapping invalidates pending frozen actions; machine APIs remain session-bound. POST installation /registered-actions freezes arguments and authority under Idempotency-Key. Signed receipts use the shared exact-byte HMAC contract in the TypeScript, Python and Go SDKs. Interrupted or unverified writes require explicit reconciliation. Reconciliation keeps the original customer/version binding and has a separate recovery bound, not business-action quota. Migrations 564–566 follow 561–563. Quiesce connector workers and deploy the matching API/worker before registered jobs. Downgrade refuses retained effect history. Customer confirmation and persistent case continuation are implemented locally; focused tests do not establish database/provider qualification. This work is unreleased.

​

Write, inspect and simulate

In AI → Procedures, select a template, inbox and exact installed operations, then write applicability and instructions. Inspect the initial graph and operation arguments in the existing grouped canvas. Missing integrations remain explicit; identity is server-bound, never collected from customer text. Instructions generates an unpublished proposal through the configured copilot and token budget. Inspect its steps before Apply to draft. The original workflow revision prevents concurrent canvas changes from being overwritten. Published edits create a separate draft without changing active admission or metadata. Versions & tests reuses workflow review, publication, pause and activation of a previous published version. Existing runs stay pinned. New APIs include /ai/procedures, version /revisions and /rollback; updates require If-Match. Simulation accepts mocked customer turns, reasoning, action results, approvals and waits. Exact expected_actions and expected_state assert dispatch arguments, authorization and verified outcomes. The interpreter has no provider or message transport. Uncertain effects hand over; later effects require fresh readback. Simulations grant no live authority. Ordinary event dispatch excludes procedure profiles. The customer AI selects eligible published procedures through bounded intent selection; a persistent case retains single ownership and pins the reviewed version. Existing customer-agent and connector opt-ins are required.

​

Current implementation boundary

Local implementation includes template contracts, scoped authoring APIs, grouped canvas steps, explicit AI draft proposals, revision-safe versioning and pure simulations. Registered case admission/continuation and exact customer confirmation APIs are locally implemented; localized web/mobile customer interfaces and built-in customer-scoped reads are connected. Improvement proposals, offline comparisons, staged rollout and scoped engineering handoffs are implemented locally; combined external qualification remains outstanding. Implementation continues sequentially, with combined external qualification after all six sequences. Existing default-off settings, permissions, approvals and budgets remain in effect; qualification metadata adds no new runtime admission lock.

​

Workflow foundation and rollback

Supported conversation changes, public messages and ticket changes enqueue workflow events in the source publication transaction. Published inbox filters are enforced against the actual subject. Private notes and redacted messages are excluded. Effects load current publisher permissions; this does not create a workspace execution grant or enable customer AI. Successful receipts preserve the complete outcome so replay cannot lose an approval wait. Older approval receipts without this evidence fail safely. Uncertain effects must not be blindly retried. Database-backed verification is outstanding; compilation is not migration validation. Migration 562 retains per-version metadata and permits identical semantic revisions. Existing labels are backfilled from current values, not reconstructed history. Its down migration refuses duplicate revisions; 563 refuses retained procedure jobs. Preserve these records rather than forcing a downgrade. Before downgrading, stop new admission and finish or explicitly cancel affected approval runs under the new worker. Retain the additive effect_outcome column until all new workers stop. Dropping replay evidence cannot safely resume outstanding approvals under older workers. This work has not been deployed.

​

Expected result

​

Common failures