Establish the single-runtime backend and G006 product-input foundation

.agents/notes/AGENTS.md

@@ -0,0 +1,7 @@
+# AGENTS.md — Agent Notes
+
+These rules apply to `.agents/notes/**` and supplement the repository-wide [instructions](../../AGENTS.md).
+
+Before creating a Note, search active Notes for an existing owner or a decision that the new work supersedes. Update the owner when the decision is unchanged; create and cross-link a new Note when the decision changes.
+
+Follow the lifecycle, classification, format, and alignment rules in [`README.md`](README.md). Do not copy current architecture or product documentation into a Note; link the owning source and record only the durable decision rationale, consequences, and verification contract.

.agents/notes/README.md

@@ -0,0 +1,64 @@
+# Agent Notes
+
+An Agent Note records a durable engineering decision: the problem it addresses, the chosen decision, the alternatives actually considered, the consequences, and the evidence that verifies the result.
+
+Agent Notes do not replace product requirements, current architecture documentation, implementation plans, test reports, incident records, or commit history. They own why an engineering decision exists and what was deliberately given up.
+
+## Path and classification
+
+Every Agent Note uses this path:
+
+```text
+{lifecycle}/{class}/yyyy-mm-dd-topic.md
+```
+
+The lifecycle is one of:
+
+- `proposed` — the decision is under discussion or implementation and has not become current repository behavior.
+- `implemented` — the decision has shipped and the Note describes current repository behavior in the present tense.
+- `rejected` — the proposal was declined and remains useful because it prevents a plausible repeated mistake.
+- `archived` — a frozen historical snapshot of an implemented decision that no longer needs current-fact maintenance. Archived Notes are not current authority.
+
+The class is one of:
+
+- `architecture` — source structure, ownership, boundaries, runtime vocabulary, or durable execution semantics.
+- `bug-fix` — a defect whose cause, contract, or prevention is likely to be revisited.
+- `feature` — a product or platform capability decision.
+- `process` — development, documentation, review, release, or operational workflow.
+- `simplification` — removal, consolidation, or reduction of owned complexity.
+- `testing` — test strategy, evidence boundaries, harnesses, or required gates.
+
+## When to write one
+
+A change is non-trivial when it alters observable behavior, architecture, ownership, a shared contract, Runtime semantics, lifecycle, persistence, configuration, compatibility, security, permissions, testing strategy, CI, release behavior, or another engineering decision a maintainer may reasonably revisit.
+
+Update the Agent Note that already owns the decision. Create a new Note only when no current Note owns it or when the decision itself changes. Purely mechanical or strictly local changes with no behavioral, contractual, architectural, or process effect are exempt.
+
+Agent Note work begins when the decision is discovered, not at Push time. The pre-push workflow is the final enforcement point: it inspects the complete outgoing change and blocks the Push when a required owning Note is missing or contradicts the code or commit history.
+
+## Required format
+
+Every active Agent Note begins with:
+
+```markdown
+# Agent Note: <title>
+
+Status: proposed | implemented | rejected — <reason>
+```
+
+Every Note opens with `## Problem` and includes `## Alternatives considered`. Lifecycle-specific content follows:
+
+- `proposed`: `## Proposal`, then plans, acceptance criteria, risks, and open questions only when they materially help decide or implement the proposal.
+- `implemented`: `## Decision`, `## Consequences`, and the relevant verification evidence or named gaps. It describes current behavior, not a migration diary.
+- `rejected`: retain the proposal and alternatives; put the rejection verdict on the `Status:` line.
+- `archived`: retain `Status: implemented`, add `Archived: YYYY-MM-DD`, and freeze the file permanently.
+
+Alternatives are recorded, never invented. State what each real alternative would have changed and why it lost.
+
+## Updating and superseding decisions
+
+Keep an implemented Note's paths, names, defaults, and mechanisms aligned with the code when the decision itself has not changed. Do not append change history; rewrite stale current facts in place.
+
+Do not edit an existing Note into the opposite decision. Create a new proposed or implemented Note, cross-link both decisions, and retain the old rationale. Archive an implemented Note only when it is no longer useful as current guidance.
+
+Code, the owning Agent Note, and commit history must agree. Code implements the decision, the Note owns durable rationale and the current contract, and the commit records the intent, scope, and verification of the concrete change.

.agents/notes/archived/AGENTS.md

@@ -0,0 +1,5 @@
+# AGENTS.md — Archived Agent Notes
+
+Archived Agent Notes are frozen historical snapshots, not current authority. Never edit, reformat, move, delete, or repair a sealed archived Note. Record new facts and decisions in an active Note or current documentation.
+
+Archiving may only move an implemented Note into the matching archived class, add `Archived: YYYY-MM-DD` below `Status: implemented`, and repair inbound links.

.agents/notes/archived/architecture/2026-08-26-sandbox-execution-venue-ownership.md

@@ -0,0 +1,33 @@
+# Agent Note: Sandbox Execution Venue Ownership
+
+Status: implemented — each code execution resolves one Sandbox backend and never retries through a separate legacy subprocess path.
+
+Archived: 2026-09-03
+
+## Problem
+
+`execute_code` selects a backend with specific isolation, network, timeout, output, and cancellation semantics. A separate fallback executor could repeat code after an unknown outcome or run it under a policy the caller did not select. Deterministic per-Agent configuration errors must also fail before Session workspace resources are acquired, while result-formatting errors must not obscure the backend's already known execution result.
+
+## Decision
+
+The workspace entry resolves and validates the effective `SandboxConfig` and execution venue exactly once for both `execute_code` and `execute_code_e2b`, before acquiring a Session execution lease, materializing a workspace, flushing output, or dispatching code. The executor consumes that resolved configuration and does not read the configuration store again. Invalid values and configuration-store exceptions return a deterministic typed configuration failure without starting execution or workspace lifecycle work.
+
+The resolved Sandbox backend is the sole execution venue. Pre-dispatch configuration or startup failures return a typed failure. Once `backend.execute` starts, an exception that leaves side effects unprovable returns `sandbox_execution_outcome_unknown`; it never starts a second backend. The platform may still explicitly resolve `execute_code` to the Sandbox subsystem's `subprocess` backend, including its configured isolation policy, but `agent_tools` has no independent legacy subprocess executor.
+
+Result formatting is post-execution presentation, not execution evidence. If a backend formatter raises, the Tool outcome retains the `ExecutionResult` success and exit-code classification, emits a bounded fallback summary, records the formatter exception type in `metadata.formatter_error`, and logs a warning.
+
+## Alternatives considered
+
+**Keep the legacy subprocess executor as an emergency fallback.** Rejected because it changes the selected execution venue and may repeat code whose first outcome is unknown.
+
+**Resolve per-Agent Sandbox configuration after Session workspace setup.** Rejected because deterministic configuration errors must fail before leases, materialization, or dispatch create lifecycle work.
+
+**Treat formatter failure as execution failure or unknown execution.** Rejected because formatting runs after the backend has returned primary execution evidence and does not change whether code ran or its exit status.
+
+## Consequences
+
+An unavailable or invalid configured backend is visible instead of silently running code under a different policy. Timeout, output capture, process cleanup, and cancellation have one owner in the selected Sandbox backend rather than a duplicate `agent_tools` implementation. Deployments that intentionally use local execution continue through the configured Sandbox `subprocess` backend. Formatter failures may reduce summary detail, but callers retain the primary status, exit-code-derived classification, and explicit formatter evidence.
+
+## Verification
+
+`backend/tests/test_sandbox_execution_policy.py` covers configured-backend failure without venue switching, invalid configuration and configuration-store failure at the real workspace entry before lease/materialization/flush/dispatch, missing or invalid E2B configuration at the same boundary, post-dispatch unknown outcomes, and formatter failure with preserved result status and metadata. The typed E2B and content-outcome tests cover explicit cloud venue selection and the no-reexecution rule. Backend Ruff formatting, Ruff checks, Pyright, and the focused Sandbox tests are the required evidence for this boundary.

.agents/notes/archived/architecture/2026-09-06-atomic-audit-records.md

@@ -0,0 +1,30 @@
+# Agent Note: Audit records share the mutation commit
+
+Status: implemented — Audit supports append and bounded Tenant reads through the caller's transaction.
+Archived: 2026-09-07
+
+The agreed [asynchronous Audit replacement](../../proposed/architecture/2026-09-06-asynchronous-audit-observation.md) supersedes this coupling as the target design. This Note continues to describe the unchanged G003 code and tests until that replacement is implemented.
+
+## Problem
+
+A required Audit record must not disappear independently of the change it describes. Actor attribution must distinguish a human Membership, platform Account, Agent/Run or named System component without accepting contradictory identities.
+
+## Decision
+
+Audit owns an append-only public service and private persistence. Its closed actor union maps to database CHECKs and same-Tenant foreign keys; an Agent's optional Run must belong to that Agent. Metadata uses one explicitly supported JSON schema version with depth, item and complete UTF-8 byte bounds, finite JSON values and recursive rejection of known Secret field names. Returned metadata is copied rather than exposing mutable ORM state. Secret-free metadata remains a caller contract; key-name validation cannot identify every possible secret value.
+
+Required Audit writes use the authoritative mutation's TransactionContext and commit or roll back with it. Audit does not start another transaction, write another owner's tables, publish success early, or provide update/delete operations. Tenant-administrator queries filter by Tenant and paginate in SQL. Actor references used only in schema fixtures are not product APIs.
+
+## Alternatives considered
+
+**Independent asynchronous Audit persistence.** Rejected for required records because the authoritative mutation could commit without its evidence.
+
+**Several nullable actor IDs without a closed union.** Rejected because contradictory attribution could be persisted.
+
+## Consequences
+
+The outer application operation decides which mutations require Audit and supplies the actor. Logging remains independent observability, not a replacement for durable Audit. Product workflow orchestration is not implemented by this service.
+
+## Verification
+
+Real PostgreSQL tests exercise all actor variants, invalid mixed actors, cross-Tenant references, Agent/Run mismatch, metadata limits, version rejection, scoped reads and rollback of a public Identity mutation when the required Audit write fails. External delivery, user-facing Audit pages and product mutation coverage remain deferred to their owners.

.agents/notes/archived/bug-fix/2026-08-26-atlassian-credential-transaction-boundary.md

@@ -0,0 +1,37 @@
+# Agent Note: Atlassian Credential and Tool-Sync Boundary
+
+Status: implemented — Atlassian credentials and assigned tools share one fail-closed persistence contract.
+
+Archived: 2026-09-03
+
+## Problem
+
+Atlassian configuration spans the owning `ChannelConfig`, discovered shared `Tool` records, per-Agent assignments, and runtime credential dispatch. Persisting plaintext credentials, accepting undecryptable values as legacy plaintext, or committing those records independently would expose a secret at rest, dispatch ciphertext as a credential, or publish configuration success without matching tool assignments.
+
+## Decision
+
+`app.services.atlassian_tool_service` owns configuration reads, writes, deletion, connection tests, Provider discovery, shared Tool upsert, per-Agent assignment synchronization, transaction settlement, and assignment cleanup. API routes authenticate, normalize transport input, and map service outcomes to HTTP. Runtime imports the service directly and never imports an API module.
+
+`ChannelConfig.app_secret` is the sole persisted Atlassian credential. Atlassian Tool config, AgentTool config, and `ChannelConfig.extra_config` never contain a credential alias; synchronization removes legacy copies while preserving unrelated config. API projections return only non-secret fields. Runtime obtains the decrypted key transiently through the strict service reader. Missing or corrupt ciphertext fails before Provider dispatch with an explicit configuration failure.
+
+One service-owned identity predicate recognizes canonical, legacy, and imported Atlassian Tool records by normalized category, name, server name, or structured canonical URL. URL identity includes default-port, trailing-slash, query, and fragment variants for rejection, redaction, and cleanup. Generic Tool creation, update, deletion, server configuration, and per-Agent credential writes cannot bypass the category configuration owner. Generic Smithery and direct MCP imports reject both requested and existing Atlassian records before mutation. Runtime attaches the authoritative credential only to the canonical HTTPS endpoint without user information, query, or fragment; a matching display name cannot redirect the credential to another host.
+
+Atlassian discovery, Tool upsert, AgentTool assignment, and ChannelConfig mutation reuse the request's `AsyncSession`. The service owns the single commit after synchronization succeeds. Missing credentials, discovery failure, empty discovery results, encryption failure, or persistence failure cannot return configuration success; the service rolls back instead. Both configuration routes await the same command and do not create unowned background tasks.
+
+Deleting either Atlassian configuration surface removes the owning `ChannelConfig` and that Agent's Atlassian `AgentTool` assignments in the same transaction. Shared `Tool` discovery records remain available for other Agents. Cleanup failure rolls back both sides, so configuration deletion cannot leave an enabled orphan assignment.
+
+Deployments that may contain pre-fix secret copies use `scripts/remove_legacy_atlassian_agent_tool_secrets.py`. The out-of-band job defaults to dry-run and processes matching Tool config, AgentTool config, and Atlassian `ChannelConfig.extra_config` in bounded batches. It removes only supported credential aliases, is idempotent, and preserves unrelated config and rows. Applying the cleanup is intentionally irreversible because legacy plaintext and corrupt ciphertext cannot be distinguished or restored safely; the authoritative encrypted `ChannelConfig.app_secret` is retained.
+
+## Alternatives considered
+
+- Preserve background synchronization and report eventual status separately. Rejected because no durable synchronization object or consumer currently owns that lifecycle.
+- Keep Tool or AgentTool credential copies as runtime fallbacks. Rejected because either copy duplicates the ChannelConfig authority and expands the secret persistence surface.
+- Treat decryption failure as legacy plaintext. Rejected because corrupt ciphertext and plaintext cannot be distinguished safely at the dispatch boundary.
+
+## Consequences
+
+Atlassian configuration may take as long as provider discovery, but success means the encrypted ChannelConfig and non-secret Tool/AgentTool records committed together. Provider unavailability is visible as an HTTP failure and does not publish partial configuration state. Removing configuration also removes only the requesting Agent's assignments; shared Tool records and other Agents' assignments are preserved. Platform startup may use `ATLASSIAN_API_KEY` transiently for discovery but never copies it into Tool config. Other MCP providers retain their existing credential contracts.
+
+## Verification
+
+Regression coverage verifies missing-key rejection before database work; category-case and URL identity variants; canonical route repair; requested and existing generic import rejection; current and proposed mutation rejection; API redaction; absence of Tool, AgentTool, and extra-config secret copies; shared-session synchronization before one service-owned commit; rollback on synchronization or commit failure; corrupt-ciphertext rejection; attacker-URL isolation; atomic deletion through both routes; and dry-run, selector, idempotence, and rollback behavior for legacy cleanup. Backend Pyright and the focused Atlassian, dynamic MCP, and LLM capability tests must remain green.

.agents/notes/implemented/AGENTS.md

@@ -0,0 +1,5 @@
+# AGENTS.md — Implemented Agent Notes
+
+Implemented Agent Notes describe decisions that have shipped. Keep their paths, names, defaults, mechanisms, and verification facts aligned with current code in the same change that moves those facts.
+
+Update factual realization in place, but do not rewrite the decision or its rationale into a different choice. A reversal requires a new Agent Note and cross-links between the decisions.