# DX Complete

DX Complete is a hosted workspace record system for humans and AI assistants.
Use it as durable context for requests, decisions, work notes, evidence, and
acceptance.

## Persistence Boundary

Conversation is state-pure by default. An assistant may read, analyze,
challenge, explain, and recommend without writing. It must not create or amend
records, Jobs, artifacts, code, communications, workflows, schedules, or other
external state unless the current instruction clearly authorizes the identified
effect. Ambiguity resolves to no action; the principal does not need to say
`off the record`.

Natural language is sufficient. Authority applies only to the identified target
and requested effect. An earlier write, an existing record, enthusiasm,
agreement, or an earlier action command does not create a continuing writing or
execution mode. A new subject returns to the discussion-first default.

## Current Connector

Connect to the consolidated MCP endpoint:

https://dxcomplete.com/api/mcp

An authenticated connection to this consolidated endpoint without a named
workspace opens **Personal Space**: the principal-specific view across
currently accessible, unmuted workspaces. Use `get_personal_space` for the
compact Attention Queue evidence, consolidated schedule, included and muted
workspaces, and the ordinary backing personal workspace. Use
`set_personal_space_preferences` to replace that principal's reversible muted
workspace set. Aggregation and muting grant no access, role, responsibility,
priority, urgency, or execution authority.

Workspace-scoped tool calls require a `workspaceId` string argument. The
workspace is not implied by a per-workspace endpoint.

## Authentication

DX Complete provides the OAuth authorization flow used by MCP clients. The
hosted sign-in page offers Google as the primary method and password sign-in for
people whose email already belongs to a DX Complete workspace. A single password
link action securely chooses setup or reset without revealing account state.
Password links never create workspace membership; they send a short-lived,
single-use verification link only when the address is eligible. Both methods
resolve to the same DX Complete principal, so workspace access does not depend
on which method was used. Assistants must leave password entry to the hosted
sign-in page and must not ask users to disclose or record a password.

## Human Access Checkpoints

Authenticated web, API, and MCP testing follows three stages:

`pre-authentication setup -> human access checkpoint -> post-authentication verification`

Keep setup and read-only diagnostics finite and bounded by the authorized test
plan. When login, MFA, CAPTCHA, consent, invitation, allowlisting, or equivalent
human action is genuinely required, stop alternate access-path exploration,
prepare the exact entry point in the in-app browser, and ask the principal to
act there. Never request credentials, tokens, or secrets in chat, substitute a
callback, cycle browser profiles, or improvise a bypass.

Resume only the frozen post-authentication plan after natural-language
confirmation and an independent check that the authenticated state is usable.
The confirmation does not itself prove authentication or expand authority.
Treat an invalid client, callback, server, setup, membership, or
authorization state as a defect rather than a login request. If the in-app
browser or session is unavailable, or access still fails, preserve sanitized
evidence and report the exact blocker.

Classify connector checks separately as connector setup, transport, live server
metadata, client authorization, client registry freshness, and direct callable
proof. A refresh or interface failure does not authorize login. Diagnostics
must never start login automatically.

For OAuth, use this ordered lifecycle:

`IDLE -> LISTENER_READY -> TAB_READY -> METADATA_READY -> CANDIDATE_CREATED -> BINDINGS_VALIDATED -> CONTINUATION_VALIDATED -> PRESENTED -> HUMAN_PENDING -> CALLBACK_RECEIVED -> AUTHENTICATED_STATE_VALIDATED -> COMPLETE`

Before creating fresh state, prove exactly one live callback listener, the exact
visible and interactive persistent in-app Browser tab, and matching live issuer
and resource metadata. Create one state and bind the listener, issuer, resource,
redirect, callback, continuation, and PKCE transaction. Validate all bindings
and the continuation page before navigating that exact tab once. Ask for human
action only at `HUMAN_PENDING`, then independently validate the callback and
usable authenticated state. PiP, previews, screenshots, DOM output, sidecars,
Chrome, and another browser do not qualify.

Any failure becomes terminal `INVALIDATED`. A pre-candidate failure creates no
attempt. A post-candidate failure consumes it. After repair, restart from `IDLE`
and allow at most one replacement. If the replacement fails, stop and escalate;
there is no third attempt.

Use these sanitized causes: metadata `issuer_missing`, `issuer_mismatch`,
`resource_mismatch`, `metadata_unreachable`; listener `listener_missing`,
`listener_multiple`, `listener_dead`, `callback_mismatch`, `listener_timeout`;
candidate and binding `state_missing`, `state_stale`, `state_duplicate`,
`redirect_mismatch`, `continuation_mismatch`, `pkce_binding_mismatch`; Browser
`exact_tab_missing`, `visibility_false`, `visibility_unsupported`,
`noninteractive_tab`, `tab_replaced`, `preview_only`; continuation
`continuation_missing`, `continuation_expired`, `transaction_not_found`,
`verifier_missing`, `scope_or_store_mismatch`, `continuation_page_invalid`;
callback and post-authentication `state_mismatch`, `issuer_response_mismatch`,
`resource_response_mismatch`, `callback_rejected`,
`authenticated_state_unusable`. Record only
a separate correlation ID, lifecycle state, cause code, UTC timestamp, client
and host build, endpoint origin and path without query, and deployment identity.
Never record raw state, verifier, PKCE material, code, token, credential,
authorization URL, callback query, or provider payload.

## Current Record Shape

Use `create_record` for new durable workspace content only when the current
instruction authorizes that identified write. Provide an explicit
workspace-unique slug and a GitHub-Flavored Markdown `body`. Freeform records receive `REC-NNNN` readable IDs as stable references, can carry optional tags, can be found by tags or text search, and can link to other records or artifacts.

Author record relationships only in the Markdown body. Use `REC-0001` or `[REC-0001](REC-0001)` within the current workspace, `[record](workspace-id/REC-0001)` across DX Complete workspaces, and an absolute DX Complete URL when needed. Put typed relationships under `## Relations`, for example `- closeout_for: [REC-0001](REC-0001)`. Remove a relationship with a targeted body patch and use `list_linked_records` for outbound and derived inbound lookup. Unresolved addresses remain visible.

`workspaceId` is the one public workspace identifier. It can be renamed, and every previous value remains a working alias.

Each authenticated user receives an ordinary personal workspace on first use.
Its normal id is `dxcuser-` plus the lowercase account email with `@` and `.`
written as hyphens. It has a declaring `home` record and otherwise uses the same
records, dashboard, email address, Daily Brief, and access rules as any workspace.
The `dxcuser-` and `user-` prefixes are reserved from manual creation or rename.
If two emails normalize to the same clean id, the first keeps it and the later
workspace receives a deterministic SHA-256 suffix; use the id returned by DX
Complete.

Personal Space and the personal workspace are different. Personal Space is an
unshared principal-specific aggregate; the `dxcuser-*` workspace is an ordinary
shareable record container. Shared matters and writes remain in their source
workspaces. Explicitly personal records go in the backing personal workspace.
Sharing that workspace does not share its creator's Personal Space preferences
or cross-workspace aggregate. All accessible workspaces are included by default.
Muting one removes it only from that principal's Personal Space and Daily Brief;
membership, source records, workflows, and every other member's view remain
unchanged.

## Starting a Session

The Principal creates Executive sessions and can keep several in progress. An
Executive session can retain long context, but it must reconcile that context
with the current accepted Target and source-workspace records.

Without a named workspace, call `get_personal_space` first and use its compact
recognition layer to identify which source workspace or matter needs deeper
context. When a workspace is named or selected, read its reserved `home` record
first. If it does not exist, use `list_records` as the workspace index. Then
call `catch_up` with a client-generated session UUID and read the returned
record headers that matter.

The same call returns applicable Namespace and Workspace policy pins and
governance-document pins. It includes text only when requested and changed.
Historical Role policy manuals remain available only by exact identity. Policy
does not grant cross-workspace access or widen authority.

Restore only the authority, limits, current matter, latest meaningful change,
exact blocker or next action, and relevant Target criterion IDs. Load deeper
records only when needed. Do not preload the full workspace, record graph,
Attention Queue, or old session transcript.

Discover current workspace-owned skills with an exhaustive `list_records` scan
using `tags: ["skill"]`. Ignore records tagged `struck`, then deep-read only the
skills needed for the current request by their `skill-{local-name}` slugs.
Source records control over stale installed copies. A skill supplies
instructions, not tools, access, permission, or execution authority.

Every record write requires `sessionId`. Normally pass the same UUID used with
`catch_up`; the write is refused when another actor added workspace events after
that cursor. Explicit `null` proceeds and records a deliberate decline of the
check. Omitting the field is rejected. `expectedUpdatedAt` remains the separate
per-record conflict check.

Successful record writes return explicit commit evidence and a verification
target. Large acknowledgements may contain only the record identity and
committed revision. Verify that revision before any retry. Request record
history only when it is needed. Never automatically retry a committed or
uncertain write. A true pre-commit rejection has no committed outcome.

Routine `update_record` and `patch_record` writes retain earlier content in
version history. They are not security redaction. Use `redact_record` only
after an authenticated principal explicitly instructs irreversible removal
from one record. Select exact `title`, `summary`, or `body` ranges with 1-based
Unicode line and column positions; the end is exclusive, so the removed text is
not sent in the request. Supply the current `expectedUpdatedAt`, `sessionId`, a
stable `idempotencyKey`, and a reason that does not repeat selected content.
The operation preserves record identity, sanitizes the selected character
lineage from live history, and leaves a content-free receipt. It does not alter
other records, backups, email, exports, or client copies. Agents may suggest
redaction but must not initiate it autonomously, and workflows do not receive
the tool.

## Direct Delivery Lifecycle

Catch Up gives each working session the current namespace and workspace policy.
A session reloads that set when relevant policy changes. Historical Role policy
manuals remain readable by exact identity but are not current policy. Policy
does not widen access, authority, or an engaged Target.

The normal Principal path is:

`Discuss -> define Target and Direction -> Engage`

- **Target** is the Principal-owned contract for the bounded end state,
  numbered acceptance criteria, constraints, and exclusions.
- **Direction** is the chosen course, constraints, and governing decisions.
- **Engage** authorizes Direct Delivery within the Target,
  Direction, and existing authority. It is not a magic phrase; equally clear
  contextual natural language is sufficient.

After Engage, the current capable and authorized session performs, checks,
releases, and closes the Target directly. It can use a bounded subagent when
distinct capability, isolation, useful parallel work, or independent review
provides a clear benefit. The subagent remains part of the same delivery and
gains no authority.

Historical organization records remain readable, but they cannot direct current
work.

For governance v2, the Principal fixes the Target statement, numbered
acceptance criteria, constraints, and exclusions when the work is engaged.
A material change needs a new Target. Reviewer advice is tied directly to the
Target and is limited to a factual contradiction against its criteria,
constraints, exclusions, or a controlling safety, access, or authority rule. It
cannot add a requirement, demand proof outside the Target, approve, block, or
start an automatic review or remediation loop. Governance-v1 history remains
readable. A durable current review uses Target-bound version 3 Reviewer advice;
versions 1 and 2 remain history only.

If the current session cannot finish, it preserves the unchanged Target,
records the exact stopping condition, evidence, and next safe action, and returns
control to the Principal. It does not create a delivery backlog, polling loop,
automatic handoff or organizational execution record. Independent workflows and schedules
remain separate services. Shared principals, repositories, projects, parent
tasks, providers, and links do not merge workspaces.

Do not create or reopen a historical organization record. Retire an eligible
ordinary nonterminal record by preserving its content, appending a dated STRUCK
notice, and adding the struck tag. Dispatcher remains technical workflow
language for independent services.

Keep these placement terms distinct:

- **Codex cloud:** an isolated hosted repository task.
- **ChatGPT Work cloud:** a hosted knowledge-work task.
- **Worktree:** an isolated checkout on the configured local or remote
  development host.
- **Local:** the active saved project or local harness.

A subagent is not proof of cloud placement. A worktree is not cloud placement
unless it actually runs in a hosted environment. Before
choosing cloud, confirm the required tools, data access, confidentiality
controls, authority, permissions, and verification capability.

Preserve the host's task-creation boundaries. DX Complete guidance does not
create an unavailable cloud launcher, silently create a user-owned task, or
turn a local subagent or worktree into cloud execution.

Model, provider, effort, tools, and subagent choices remain delivery
choices inside the current session. They must remain within approved access,
confidentiality, cost, and provider boundaries and never expand authority.

A bare `proceed` or `continue` advances one legitimate lifecycle transition. It
does not Engage an unresolved Target or run every remaining transition through
completion. When the next transition branches, present the exact choice. When
a condition prevents advancement, report the exact condition.

Terminology is deliberate:

- **Target** is the current durable contract for accepted work.
- **MCP Task** is a protocol-defined asynchronous-operation handle and is not
  a DX Complete delivery record.
- **workflow run** is one execution of an independent workflow definition.
- **condition** is a decision, date, access grant, dependency, evidence
  requirement, or other prerequisite; it is not agent work by itself.
- **historical organization record** keeps its stable identity, history, and
  links but cannot direct current delivery.

Additional scoped action vocabulary is:

- `Memorialize` preserves identified context without creating work.
- `Propose` creates or continues one durable idea.
- A clear lifecycle `Recommend` direction for one identified durable idea
  creates its decision case without accepting or defining a Target. An ordinary
  request such as `what do you recommend?` remains state-pure discussion.
- Resolve Engage against an explicitly named or single unambiguous Target. If
  several Targets are plausible, ask. A workspace-wide engagement must be
  explicit.

### Candidate evidence

A candidate is source-supported evidence of a potentially material unresolved
matter that merits explicit disposition before it enters the appropriate
lifecycle. It is not automatically an idea, Target, priority, fact,
incident, governance outcome, or authorization.

Qualify it only with an exact source and revision, bounded evidence, plausible
material consequence, no adequate current representation or disposition,
coherent scope and next transition, observed evidence separated from inference,
and authority neutrality. Record confidence and plausible impact separately.
Use one kind: `idea or opportunity`, `signal or anomaly`,
`dropped follow-up or gap`, or `cross-scope matter`.

Initial disposition is `unreviewed`. Durable dispositions are `promoted`,
`merged/already represented`, `dismissed`, `routed`, `deferred` with an exact
reconsideration trigger, and `misclassified/not a candidate`. Indefinite
`parked` is invalid. Ideas hand off to Propose; signals hand off to verification
or triage; gaps first identify the missing next object; cross-scope matters
normally route on the origin candidate, with separate authority required for a
destination-workspace write.

For a complete read-only inventory, exhaust separate `list_records` scans for
the `candidate-review` tag, `CAND-` and `GEN-` body searches, and unfiltered
current headers. Repeat the same query and page size through every cursor
within each scan. Add explicit candidate-review slug or title identities,
union by stable record UUID, omit struck records, and deep-read every union
member with `get_record`. Treat a body as an owner only when it defines the
stable candidate and its current disposition; skills, historical Jobs, inventories,
sources, and other references are not owners. Report ownership collisions or
malformed owners instead of guessing.

Candidate state lives in the owning body; never trust a summary, secondary tag,
or one tag scan as the authority. Report total and unreviewed candidates,
per-disposition counts, kinds, exact source revisions, and kind-specific
next paths. Listing creates no Target, authority, urgency, notification,
reader obligation, disposition, or source mutation.

Agents carry the burden of context; principals retain the authority to decide.
Every material briefing item should restore recognition with the stable
identifier and name, what the matter is and why it exists, current lifecycle
position, latest meaningful change, next legitimate move or exact condition,
and whether principal action, awareness, or an unknown relationship applies.
Expand with provenance, history, options, consequences, uncertainty, and a
recommendation only when the compact recognition layer is insufficient.

The three briefing products are distinct:

- **Work Brief** is an on-demand, self-contextualizing view across active
  pipeline matters.
- **Attention Queue**, also invocable as **What's Next**, is the current
  material subset that warrants attention now.
- **Daily Brief** is the scheduled, UTC-dated updates-only projection persisted
  in each workspace and filtered per recipient across that recipient's
  accessible, unmuted workspaces. It reports material source changes and
  qualifying events in the next seven days. Silence is normal when nothing
  qualifies.

All three are views over current records. Inclusion does not assign
responsibility, create urgency, accept intent, create a Target, authorize
execution, or require the reader to act.

## Global Writing Standard

Apply the current Global Writing Standard at
`https://dxcomplete.com/dxcomplete/REC-0674` to agent-authored prose. Use
ASD-STE100 Simplified Technical English for technical documentation and
instructions when appropriate. Test other prose for simplicity, brevity,
clarity, and humanity. In ordinary discussion, lead with the shortest useful
plain-language answer. Do not volunteer technical or behind-the-scenes detail by
default; include it when requested or materially needed. Use progressive
disclosure: recognition first, then the decision context needed. Preserve
material context, evidence, uncertainty, exact source text, and authority
boundaries. Say `STE-aligned` unless formal conformance was validated. The
standard guides writing quality and grants no record, publication,
communication, execution, or other effect authority.

## Material Principal Questions

When a real blocker, approval, load-bearing decision, material scope or risk
choice, or authority gate needs principal input, apply the current decision-question policy. Do not turn pleasantries, routine clarification, or agent-resolvable
facts into a questionnaire.

Before asking, restore concise context: the human-readable matter and source,
what it is and why it exists, current position, latest meaningful change, the
gate, why it matters now, scope and exclusions, and the authority boundary.
Always state the agent's recommendation — what it would choose within that
scope — with the brief basis and main tradeoff. A recommendation is advisory
unless the principal explicitly delegates that bounded decision; delegated
discretion does not widen authority or replace readiness or Target-specific
execution authorization.

Number questions within one assistant message. If that message contains
multiple independent questions, label them `Q1`, `Q2`, and so on in message
order. A single-question message may remain unnumbered; if a label helps, use
`Q1`. Restart numbering in the next assistant message. Across messages, refer
to the matter or question subject rather than a bare earlier Q-number. A
conditional follow-up in the same message may say `Q2 (only if Q1=A)`; when it
is asked in a later message, restart at `Q1` and restate the condition. Keep
each question atomic and separate guidance, RFI, acceptance, Target definition,
and execution authorization. Put context, why the answer matters, options,
recommendation, and exact no-answer consequence before a final plain question.
Make replies easy to parse, such as `Q1 A; Q2 No`; silence is never approval,
and a naked approval request is not valid.

## Client Status Reports

For a client-facing project status report, read the current
`dxcomplete/REC-0459` global standard and `dxcomplete/REC-0461`
`skill-client-status-report` source before drafting. Resolve one target
workspace by default, then apply the global standard, one explicitly selected
delivery-vehicle profile if any, one current workspace/client profile if any,
and explicit direction for the individual report.

Discover a workspace/client profile with an exhaustive paginated
`list_records` scan for `tags: ["status-report-profile"]` in the target
workspace. Select only a current, unstruck profile that links to the global
standard through `specializes_status_report_standard`. One match is selected,
none means the global standard applies alone, and multiple matches are an
unresolved conflict unless current direction selects one. A delivery-vehicle
profile applies only when explicitly named or linked from the selected
workspace/client profile through `uses_delivery_vehicle_profile`. Do not infer
a profile from common ownership, access to several workspaces, or record
proximity.

Profiles may specialize presentation but cannot weaken evidence fidelity,
honest uncertainty, end-to-end completion, defensible denominators,
attribution, authority separation, or effect separation. Analysis and a
report returned only in the current conversation are read-only. Saving a report
record, creating a persistent artifact, marking approval, sending email, and
publishing are separate effects that each require clear authority. Historical
reports remain readable evidence and are not rewritten after a standard or
profile revision.

## Self-Service Workflows and Schedules

A workflow defines what an agent should do. It is not inherently email-based
and may be invoked manually or referenced by any number of schedules. A
schedule stores timing only, defines when one active workflow becomes eligible,
and always references that workflow. A workflow run is the durable execution
record for one manual invocation or one nominal scheduled boundary.

Execution is workspace-scoped by default. Use `executionScope: account_workspaces`
only for a workflow that must process the same authenticated
principal's currently accessible workspaces. The workflow, schedule, and run
remain bound to that principal; the scope grants no access, role, or authority.
Another member cannot execute it under the bound principal's credentials, and
this scope is available only through the consolidated MCP endpoint.

`hostCapabilities` is a separate finite list of provider-qualified host
requirements. It grants nothing. Any workflow that declares one is
workspace-creator and execution-principal bound even when its execution scope
is `workspace`; the dispatcher may use it only when the current callable
registry matches the pinned declaration unambiguously. DX Complete actor IDs
must match each other; a connector actor email separately matches the DX
Complete actor email. Built-in OpenAI host capabilities have no separate
connector principal.

To schedule new work, create or reuse the workflow, translate the user's
intended timezone into exact UTC timing, then call
`create_workflow_schedule`. Creating a schedule does not run it immediately.
Use `set_workflow_schedule_status` with the current record version to enable or
pause a nonterminal schedule. Enabling strictly revalidates the linked active
workflow and principal. Pausing is fail-safe containment through the
authenticated schedule binding even if the linked workflow is missing, struck,
or malformed. The operation preserves cadence and durable run state; generic
record updates cannot mutate schedule contracts, and completed one-time
schedules cannot be resurrected. Pausing does not cancel an already-created
run.
When due, the cloud dispatcher uses `claim_workflow_schedule`, calls
`trigger_workflow` with `source.kind: schedule`, the returned claim, and exact
stored boundary, then calls `record_workflow_schedule_run`. It uses
`claim_workflow_run` and `finish_workflow_run` for each bounded run transition,
and `advance_workflow_schedule` only after the associated run is complete. The
service creates and validates leases; agents do not edit workflow state through
generic record operations. For an explicit manual invocation, call
`trigger_workflow` with `source.kind: manual` and a stable operation key.
Successful nonterminal transitions finish with outcome `continue`, which
returns the run to pending without error evidence or schedule advancement.
`compute_sha256` provides deterministic exact UTF-8 reconciliation digests.

A new, rebound, or resumed hosted dispatcher must record one immutable
`dispatcher-activation` receipt on its first natural scheduled wake before
business processing. The receipt uses a deterministic record slug, reports the
actual saved client's callable mappings and identity evidence, and has no
business effect. Its deterministic write uses `sessionId: null` so it does not
advance the dispatcher's business catch-up cursor. Runtime tool inventory is
server evidence and cannot
substitute for the saved client's registry. Missing, stale, ambiguous,
mismatched, and unavailable evidence remain distinct; only a current passing
receipt permits business processing. Failed or incomplete receipts are not
rewritten. A replacement task generation records a later receipt and preserves
the earlier evidence.

`replyMode: none` means the run completes without reply-driven continuation;
it may still send email when its instructions and allowed tools call for it. `replyMode:
record_thread` allows a valid opaque-token reply on that run's stored DX
Complete email thread to continue the run. `email_external_record_message`
provides email transport, thread storage, and reply ingestion, but does not by
itself create, resume, or complete a workflow run.

`get_daily_brief` is state-pure. Its default `latest` mode returns the most
recent persisted model-authored Daily Brief for one workspace. Its `updates`
mode requires a UTC Brief date and returns a bounded candidate packet of
eligible changed sources and newly relevant seven-day events for the scheduled
model review. It does not decide materiality or advance recipient observations.
New reports use `daily-brief-YYYY-MM-DD`. Historical `agenda-YYYY-MM-DD`
records remain readable as explicitly identified legacy evidence.

`deliver_daily_brief` is the idempotent, deterministic effect used by the
principal-bound system delivery workflow. It requires the current claimed run
and generation schedule, refuses partial delivery until the same UTC date's
generation run is complete, then applies current membership, mute, recipient
baseline, event-deduplication, and idempotency rules itself. It sends no email
when no eligible item remains. Assistants must not reconstruct consolidation
with generic email tools.

`get_workflow_health` checks workflow definitions, schedules, runs, claims,
retries, associations, Daily Brief readiness, dispatcher activation receipts,
and the current server version without changing anything. Its versioned
findings include evidence plane, severity, timestamps, and a recommended next
step. Server evidence, durable client-attested receipts, and unavailable direct
host inspection are separate. Installed connector bindings and scheduled-task
settings must still be checked directly in the client when the host exposes
them. Use the current `Diagnose Workflows` workspace skill to combine those
views when direct client inspection is available.

## Record Conventions

Do not create or reopen organizational execution records. Open-work readers
still include historical `job` and `task` records and deduplicate mixed-tag
records by stable identity. Add dated reminder amendments for escalation. To retire a record,
append a dated `**STRUCK**` notice and add the `struck` tag. The record, links,
and history remain readable.

Security redaction is the narrow exception to history preservation. It requires
an explicit current-member instruction, removes only the exact selected
character lineage from one live record and its live history, and leaves an
attributable receipt without the removed content.

An event is an ordinary record tagged `event` with a `when:` line in its body.
The line may use a crisp date/time, a range, or fuzzy wording such as `late July`
or `sometime this quarter`, for past or future events. Sharpen fuzzy timing by
amendment and append outcomes after the event. Use `list_records` with the
`event` tag as the calendar query; recurrence remains cadence or automation data.

## Ambient Hygiene

When an agent is already adding or updating a workspace record, it may also tidy
the workspace home/index record at its own discretion: link the new record, fix
obviously stale text, or connect related records. This is ambient hygiene, not a
standing duty. A full audit, reorganization, or renovation remains separate
tasked work.

## Artifacts

For original-format source evidence such as notes, PDFs, images, audio, or
video, reserve an artifact upload, send the bytes directly to the signed GCS POST
target, and complete the upload. The completed artifact includes a stable
artifact reference and Markdown links. Artifact objects are stored under a
workspace-scoped GCS key prefix and are served through authenticated read-only
links.

## Dashboard

The dashboard is available at:

https://dxcomplete.com/{workspaceId}

It renders freeform Markdown records, resolves record links, and opens
artifact links for signed-in workspace members.

## Useful Links

- Start here: https://dxcomplete.com/outcomes
- Flow: https://dxcomplete.com/operating-guide
- Records: https://dxcomplete.com/records
- People: https://dxcomplete.com/principals-agents
- Account and onboarding: https://dxcomplete.com/account.html