Standards library

Status: Phase 1 shipped; multi-dimension index trees + full-screen three-pane admin UI (2026-07-25) shipped API and /workspace/standards; source crawl / impact lists still pending.

Truth: User-visible capabilities in docs/产品规格.md §3.2.2; this page is for design and implementation mapping.

Voice: UI and help use user language (“standards library”, “published”, “pending review”, “browse by region”, and so on); table names, APIs, and paths appear only in §7.

Related:

• 产品规格.md §3.2.1 (three layers of knowledge documents), §3.2.2 (standards library), §4.2.4 (platform plugins)
• 智能体调用知识文档的方式.md (conversation retrieval)
• 资料库.md (blank forms / filing templates; may “cite” entries in this library)
• 检查方案.md (practice machine packs; must cite entries here, must not impersonate the text)
• 合规实践检查表转机读包.md (expert table → machine pack → check scheme)
• 工作区能力包.md (work assistants fetching from the web)
• ../sdk/platform-plugin/README.md (platform plugins reading standards / calling each other)

1. Goal

• Inside a workspace, provide a shared source of truth for laws, industry standards, management policies, and management theory (user language: standards library).
• Let platform plugins such as HR and compliance generate questionnaires, check items, grades, and competency data from the same source.
• Let work assistants (or scheduled tasks) fetch updates from registered official sites, then after human review and publish, affect plugins and conversation.
• Let agents answer from published standards and, where possible, land on document number / version / source.

1.1 Non-goals (first phase)

• Do not replace each plugin’s own business store (rosters, inspection instances, remediation tickets still live in the plugin).
• Do not make the standards library an alias of ordinary “workspace knowledge” folders (see §2).
• Do not allow “the site was crawled, so checklists / grade data / public wording change automatically”.
• Do not require plugins to crawl each other’s Markdown on disk.

2. Split from “workspace knowledge documents”

| | Workspace knowledge documents | Standards library | |--|-------------------|------------| | Who it mainly serves | Conversation Q&A, team wiki | Plugin-generated rules and data, compliance citations, article Q&A | | Typical content | Process notes, FAQ, project background | Government / industry law, management policy, competency theory as source of truth | | Change gate | Maintainers can edit directly | Draft → review → published; laws default to human review | | Version and effect | Weak | Strong (document number, in-force / repealed, source URL, content hash) | | For plugins | Usually does not drive writes | A published version may drive questionnaires / check items (must confirm again) |

Optional: when a standard is published, sync a conversation summary into workspace knowledge; source of truth and version still come from the standards library.

3. Product decisions (confirmed, 2026-07-25)

4. User-visible capabilities (planned)

4.1 Standard entries

Each standard should let the user understand at least:

• Title, body (or attachment)
• Type: law / industry standard / internal policy / management theory, and so on
• Domain tags (UI suggests defaults such as HR / labor / compliance / competency; users may add their own; plugins filter by machine values such as hr, labor, compliance, competency)
• Document number / issuing body (legal types)
• Effective date, repeal date (may be empty)
• Source: manual upload / official-site crawl (including URL)
• Status: draft, pending review, published, repealed
• Version (increments under the same document number, or by publish batch)

4.2 Source allowlist

• Workspace admins register official domains and entry pages that may be crawled (plus optional parse notes / skills).
• Addresses not on the allowlist: must not auto-crawl into the standards library.

4.3 Crawl and pending review

• A work assistant or scheduled task checks updates on the allowlist → compares document number / content hash / effective info marked on the site.
• On change, create a draft or pending-review entry and a change summary (a human-readable diff vs the last published version).
• Laws and mandatory industry standards: default must be human-reviewed before publish.
• Internal policies: policy may allow “low-risk auto-publish” (human review still recommended by default).

4.4 Publish and enable

• Review passes → published; may set an enable date (aligned with the legal effective date).
• Support rollback to the previous published version (unconfirmed plugin recalculations may be cancelled).

4.5 Impact list for plugins

After a standard is published, the platform notifies subscribed plugins by domain tag (e.g. HR, compliance):

• List capabilities that may be affected (questionnaire templates, check items, grade packs, and so on).
• Plugins provide “preview against the new standard” → confirm → write the business store.
• Each generation must record: standard ID + version (audit and trace).

4.6 Agent Q&A

• Retrieval scope: published, enable date reached, not repealed.
• Answers should cite the basis (title, document number, version, or source link) where possible.
• Looking up “current workspace business facts” (roster, a given inspection conclusion) still goes through each plugin’s operations (e.g. plugin_invoke); do not impersonate live business data with the standards library.

4.7 Multi-dimension index trees (browse and manage)

Standards often need to be arranged by region, industry, effect type, business domain, and so on; users expect a tree on the left and a way to switch “how we index”. That is easy to confuse with §3.2.1 knowledge-base trees; the contract is below.

#### 4.7.1 Product principles

#### 4.7.2 User language

• Index mode: switch in the top or side, e.g. “by region”, “by industry”, “by type”.
• Classification tree: nodes under the current index mode (add / edit / delete / sort; admins maintain).
• Uncategorized: entries not attached to any node in the current dimension sit in their own column, so existence is not “only if it is in a folder”.

#### 4.7.3 UI skeleton (next stage)

┌─────────────────────────────────────────────────────────────┐
│ Standards library     [By region ▾]     Back to workspace collaboration │
├──────────┬────────────────────┬────────────────────────────┤
│ Classification tree │ Entries under the current node │ Title / metadata / body │
│ (expandable)│ (status, document number, version) │ Save draft · submit · publish… │
└──────────┴────────────────────┴────────────────────────────┘

• Look and feel may align with the knowledge-document admin “three panes”, but the left is the classification tree of the current index, not a knowledge/ directory.
• The collaboration page may keep a short intro + “Manage standards library”; full editing goes to a dedicated full-screen route (same idea as “Manage workspace knowledge base”).

#### 4.7.4 Sketch

Standard entry: Labor Contract Law of the PRC v3 (published)
  ├─ On the “region” tree: National → Labor and employment
  ├─ On the “industry” tree: Generic → Human resources
  └─ On the “type” tree: Law

Plugin subscribe may still filter published entries by domain tag or index node ID; when generating business data, record standard ID + version (and optional node path for audit display).

#### 4.7.5 Implementation mapping (shipped)

Still pending: source-allowlist crawl, plugin subscribe by node, impact lists, and so on.

5. End-to-end flow

flowchart TD
  A[Official-site allowlist source] --> B[Work assistant or scheduled crawl]
  B --> C{Differs from published version?}
  C -->|no| D[Record check time]
  C -->|yes| E[Standards library draft / pending review]
  E --> F[Admin review]
  F -->|reject| G[Keep a trace]
  F -->|pass| H[Published + optional enable date]
  H --> I[Available to conversation retrieval]
  H --> J[Notify subscribed plugins]
  J --> K[Impact list and preview recalculation]
  K --> L[After human confirm, write plugin business store]

6. Plugin and cross-call boundaries

Agent ── retrieve ──────────────► Standards library (what the text says)
Agent ── plugin_invoke ─────► HR / compliance (what is in the store now)
HR / compliance ── read-only API ───────► Standards library (same source of truth)
Compliance ── platform-signed call ────────────► HR (business facts such as people only)

7. Implementation mapping

Added (2026-07-25): Workspace collaboration UI “Standards library”; conversation runtime injects published standards (workspaceStandardsBlock).

Added (import/export): Full-screen admin “Import / Export”, same family as knowledge documents; on cross-workspace migrate, classification is rebuilt from slug + title path.

Added (agents writing article drafts): System tools workspace_standard_list / workspace_standard_write (user must confirm; draft only, no publish). Practice machine packs must not impersonate law with these tools; see 检查方案.md.

Still not implemented (later): Official-site allowlist and auto-crawl, plugin subscribe and impact lists, cross-plugin business signed calls, admin ops page.

8. Acceptance

8.1 Phase 1 (storage + draft/publish + plugin read-only) — API shipped

• [x] Workspace members with JWT can create drafts and submit for review; admins can publish / repeal / reopen.
• [x] Ordinary member lists see only published, in-force standards.
• [x] Plugin launch_token reads published standards only (including filter by tag).
• [x] Body is separate from the knowledge directory; publish writes a version file.

8.2 Multi-dimension index and admin UI — shipped

• [x] Workspace presets region / industry / type indexes; tree nodes can be added and removed.
• [x] The same standard can hang on multiple nodes under the current index; “Uncategorized” is visible.
• [x] Full-screen admin: index switch + left tree + list + right editor; does not write knowledge-document physical paths.
• [x] Publish gates and member/plugin visibility are not bypassed by tree browse.

8.3 Later

• [ ] URLs outside the allowlist cannot write auto-crawl results.
• [ ] Unpublished standards do not appear as the help assistant’s basis for ordinary members (conversation retrieval is partly covered; crawl path still pending).
• [x] HR onboarding uses the product default machine-readable competency pack (does not scan the standards library); follow-up versions read one bound entry ID (mindlink-competency-pack, 2026-07-25); platform-level impact lists still pending.
• [ ] After a new version is published, an impact list appears; the business store is not silently changed (HR already has “preview new standard → confirm apply”).
• [ ] Can roll back a published version; audit can show “who crawled, who published, who confirmed recalculation”.

9. Revision history