Extend Onboarding and Context

Onboarding Ownership

Original sources and semantic Context live in object storage. PostgreSQL coordinates onboarding status, the furthest explicitly completed setup step, chats, revisions, and activation. Source manifests live with their immutable bytes in object storage. The generated review is agent-authored untrusted input and must pass backend preflight before activation. Frontends resume the setup flow until the durable kickoff turn exists; creating the organization shell does not complete setup. Integration choices remain onboarding discovery state, while credential and readiness state comes from the canonical organization integration projection. Refresh that projection when the setup tab becomes visible again so a connection completed in a separate tab appears without restarting setup.

After setup starts, Chat releases one bounded Operator discovery graph. The scheduler admits only that graph before activation: each task has one exclusive organization-discovery input, a zero action budget, and read-only integration access. Ordinary tasks, schedules, and consequential provider actions remain unavailable until the organization is active. Empty connector lists are valid so public and owner-provided evidence can still drive onboarding without an upfront connection.

Add a File Type

1. Define extension and media-type acceptance.
2. Set explicit filename and size limits.
3. Parse or extract without executing embedded content.
4. Normalize text to UTF-8.
5. Preserve the original source and record a typed derived artifact when needed.
6. Reject absolute, traversing, symlinked, or unsafe object paths.
7. Add malformed, oversized, mislabeled, and unsupported-file tests.
8. Update the onboarding UI accept list and Upload Reference.

Do not accept a format merely because a browser can preview it. It must produce safe, deterministic evidence for the runtime.

Extend Structured Questions

Question types and answer payloads are bounded shared contracts. Preserve ordered question IDs, required/skippable semantics, attachment ownership, and the one-to-seven schema limit. Onboarding may ask one batch per turn for human-owned decisions while public and connected-system discovery continues, then ask further batches on later turns. It must consume retained evidence and wait for covering discovery instead of asking the owner to restate discoverable facts. After those paths are exhausted, it may ask for a still-required unavailable fact. Questions must not combine these evidence classes or duplicate pending candidate findings and grounded answers. The backend binds each batch to its assistant message and tool part because provider part labels may repeat between turns. Asking to reopen a discoverable gap does not turn it into a blank questionnaire: the agent must present its evidence-backed understanding through the finding review, where the owner can accept, edit, reject, or defer it. A sufficiently grounded organization may need no question batch. While discovery remains active, the onboarding page shows progress and refreshes its projection in the background so completed findings appear without a manual reload. The same projection includes durable planned, finished, and remaining step counts plus a bounded recent-activity window. The backend converts retained run events to fixed user-facing messages and omits commands, tool and provider names, payloads, paths, and runtime identifiers before returning them to the browser. Pending findings render after the current transcript one at a time. Back and Continue preserve draft decisions, and the browser sends one complete generation- and revision-fenced confirmation only after each finding has an explicit decision.

When adding a question capability:

• update shared types and Zod validation;
• update the trusted structured-questions MCP server;
• update frontend rendering and draft preservation;
• validate final ordered responses in the backend;
• add message, attachment, and navigation tests; and
• document operator behavior.

Extend Activation Review

Preflight activation against organization identity, selected departments, retained sources, operational minimum, and known gaps. Invalid agent-authored review content must become a recoverable issue, not take down the conversation page. Before activation, Context Health must remain uninitialized until that provisional review passes validation; never synthesize a partial health manifest from inconsistent review data.

The review sources[] inventory contains exactly the raw manifests under onboarding/sources/. Public research, connected-system evidence, human decisions, and world-model claims may ground Context through evidence references but never belong in that raw-source inventory.

Extend Context Structure

Use a stable file path and explicit evidence metadata. Promote verified reusable facts, policies, decisions, and workflow knowledge—not temporary drafts or hidden reasoning.

contextctl verify may validate staged local structure but remains read-only and network-free. Promotion belongs to the authenticated backend control plane.

Keep all integration meaning in preferences.toml under the immutable connector key generated from the provider identity and authorized department scope. Organization records own permission mode, purpose, policy, functions, typical work, workflows, and department grants. Department records own only scoped meaning and usage. Operational credentials, readiness, enabled tools, and provider resources remain PostgreSQL state and must not be copied into semantic Context.

Keep existing know-how in workflows.toml, scoped to organization or department. Chat requests to create or edit a workflow must become a structured Context task owned by Operator or the named department, stage the complete changed document, verify it, collect human approval over the diff, and promote through the backend revision boundary.

Add an Audit Rule

Define the scope, evidence requirement, severity, durable health payload, and remediation path. Make repeated audit execution idempotent and preserve historical health revisions.

Integration-Scoped Context Review

Keep full Context audits and integration reconciliation as typed, mutually exclusive task variants. The full branch may inspect all Context and retained onboarding evidence. The integration branch may inspect only the affected safe-registry records, previous health, and exact relevant facts and workflows. Backend hydration and promotion validators enforce that boundary; prompt prose is not a security boundary.

integration_usage.key remains the semantic workflow reference. Optional connector_key links the usage to an exact current registry key. Do not infer connection state from organization.constraints.allowedIntegrations, profile mcpServerKeys, provider display names, or onboarding prose.

Use typed durability for pending connector keys and at most one active review rather than adding a parallel health table. Queue the durability update in the same transaction as the material registry change, attempt immediate materialization, and let scheduler recovery close failures and restarts. Scoped promotion must fence the health revision, registry revision, authorization epoch, relevant Context hashes, and request generation before merging only the reviewed integration findings.