feat(space): make documents the authoring surface, split Workspace from Space (专项作战人机协作区) #558

Preflight

• I searched existing issues and PRs; no duplicate. Closest prior art is feat(workspace): make user goals the spine of multi-agent collaboration #222 (goals as the collaboration spine) and feat(memory): Obsidian-style live Markdown notes in Memory & Collaboration #511 (obsidian-style live Markdown), both referenced below.
• I read AGENTS.md / contributing conventions for this repository.
• I can describe the change without touching the engine contract.

Summary

Today a user defines work through forms: "新建项目" is a modal with fields, "目标" is a field editor, tasks live in a board. That reads as a database admin tool, not as a place where a human and a set of agents work together. The proposal is to make documents the primary authoring surface, and to introduce a two-level naming system — Workspace (工作区) and Space (专项作战人机协作区) — that matches the existing on-disk model instead of fighting it.

Three concrete asks:

1. Work should be defined in a beautified, structured Markdown document, not a modal form. The agent drafts a first pass; the human confirms and edits in place. One file, two renderings (document view ↔ structure view) — never two copies of the data.
2. Projects and the inbox are not peers of the org. They should live inside a space: Workspace > Space > Files.
3. When the human is the blocker, there must be one place to approve and one place to accept. These are two distinct acts and must not be merged.

Evidence from the current tree

The key asymmetry: approval is fully modelled, acceptance is not. That is why "我在卡点上" currently has nowhere to land.

Naming

The existing vocabulary overloads "空间" / "space". Split it:

• Workspace (工作区) — the top-level container. One organization + one file root. Maps 1:1 onto the existing workspace.v1alpha1 manifest. One workspace is open at a time.
• Space (专项作战人机协作区, shown compressed as 协作区 in the rail) — a folder inside a workspace where one objective is fought. Hierarchy: Workspace > Space > Files.

This follows the data model instead of inventing a parallel one: a workspace already has exactly one organization, and a space is just a folder.

Document-driven collaboration

A space is a folder. Its spine is one Markdown file (e.g. 目标.md) that is the single source of truth:

# 目标：<title>

## 验收标准
- [ ] <criterion>

## 任务
| 任务 | 状态 | 负责岗位 | 截止 |
| --- | --- | --- | --- |
| ... | ... | ... | ... |

• The human writes prose freely, anywhere in the document.
• The agent parses fixed H2 headings to extract structure. No custom DSL, no front-matter schema to maintain.
• The agent's output is written back into the same folder, so prose and structured rows stay in one artifact.
• The document view and the structure view are two renderings of one file. Editing a row in the structure view edits the document; editing the document updates the structure. There is never a second copy.

Who is the owner

• owner comes from OrganizationFile.owner, not from a per-space field. It points at the root position.
• Every space shows its participants (which agents took part) and marks one owner visually.
• Goal / project-management / progress reuse existing components rather than new bespoke ones.

Acceptance vs approval

Two lanes, deliberately not merged:

• Approval — belongs to the workspace/org. Reuses the existing ApprovalRecord. Triggered when an action needs permission (e.g. a read_only position requests network). Answered by the operator.
• Acceptance — belongs to the space. Has no domain model today. Triggered when the human is the blocker on a deliverable. The human ticks criteria one by one, with an optional evidence path per criterion; "accept" stays disabled until every criterion is ticked; "reject" carries a note.

Hard constraint carried over from goals.ts: GoalWorkItem and GoalTaskExecution never overwrite each other. An agent may only push an item to review; only a human acceptance may write done.

Inbox

The inbox is a cross-cutting view, not a container:

• "协作区待办" — items that have a home; clicking jumps back to the space.
• "组织待办" — items that belong to no space; no jump target.

Proposal — the acceptance.v1 contract

The only genuinely new domain object this needs. Shape mirrors goal.v1 conventions (fail-closed validators, allowlisted keys, closed enums, bounded text):

export const ACCEPTANCE_SCHEMA_VERSION = "acceptance.v1" as const;

export interface AcceptanceRecord {
  schemaVersion: typeof ACCEPTANCE_SCHEMA_VERSION;
  acceptanceId: string;
  spaceId: string;
  source: {
    positionId: string;
    turnId?: string;
    artifactPath?: string;
  };
  verdicts: Array<{
    criteriaIndex: number;
    passed: boolean;
    evidencePath?: string;
  }>;
  decision: "accepted" | "rejected";
  note?: string;
  decidedBy: string;
  decidedAt: string;
}

Invariants a validator must enforce:

• decision === "accepted" requires every criterion index present and passed: true.
• decision === "rejected" requires a non-empty note.
• criteriaIndex values must be unique and non-negative.

Scope for this change

To keep the first PR reviewable, this only lands the contract + tests, not the UI:

• New: packages/shared/src/acceptance.ts — the contract above plus a fail-closed validateAcceptanceRecord.
• New: tests covering the invariants listed above.
• Exported from packages/shared/src/index.ts.
• No renderer changes yet; the space/doc UI lands in a follow-up once the contract is agreed.

Assumptions

• A space is a folder under the workspace root, not a new persisted entity with its own manifest. If a space later needs durable metadata, it goes in a sidecar file inside the same folder rather than a new store.
• Fixed H2 headings are sufficient structure for v1; a richer syntax can come later without breaking the document.
• Acceptance is per-deliverable and append-only. Re-accepting after a change produces a new record rather than mutating the old one.

Acceptance

• validateAcceptanceRecord rejects an accepted decision that is missing a criterion or has one passed: false.
• validateAcceptanceRecord rejects a rejected decision with an empty note.
• validateAcceptanceRecord rejects duplicate criteriaIndex values.
• validateAcceptanceRecord rejects unknown top-level keys and an unsupported schemaVersion.
• packages/shared/src/index.ts re-exports the new module.
• pnpm test for the shared package passes.

Refs #222, #511.