docs: define Deep Research and project portability contracts #77
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,13 @@ | ||
| --- | ||
| topic: OpenCLI Agent-First Operations System | ||
| updated: 2026-08-24T12:44 | ||
| --- | ||
|
|
||
| - (event) 当前 Agent Home 被判定为错误方向：三栏空壳、虚假的 Requirements/Plan/Evidence、全 mock 验收以及登录状态 401；决定重新定义整套 Agent 系统，再进入 UX 和 Designer Pipeline。 | ||
| - (decision) 产品定位：OpenCLI 是本地部署的 Agent-first 爬虫与数据上游平台；通过 Agent 将采集目标持久化为项目，借助工作流发布插件，把浏览器执行节点与数据结果自动关联；负责信息获取与拆解，供下游 Agent 或其他系统消费；不做 SaaS 工作部署平台，也不接受低自动化、难部署、难扩展的工具形态，并需对齐现有 OpenCLI 与 CloseI。 | ||
| - (decision) 首要演进方向是 Deep Research：一级目标依次为实时获取信息、强化 Deep Research 能力、维护可信源数据链（最关键）。当前核心痛点是不智能、难部署、难复用；多源数据杂乱且缺少统一可消费契约，使下游 Agent 难以使用，Deep Research 能力因此薄弱。智能化应建立在可追踪、可复核、可更新的源数据链上，而不只是聊天交互。 | ||
| - (event) 上游 Issues/PRs 复核确认：产品不是从零开始。已合入的基础包括 thin-channel/thick-runner 采集框架、真实浏览器/Crawl4AI/RSS/OpenCLI 来源、MCP、SourceBinding 与受治理 Agent Control、DataFlow 清洗与 provenance、存储级去重、API-first runtime evidence、自托管安装、后端权威能力节点和 SearXNG/RSSHub；仍在开放或部分实现的包括 L1 通用采集节点与逐源 lineage、多 Agent CAS 编辑、schema drift 传感器与适配器自愈、统一插件中心、持久 Agent Run 和外部 Agent runtime。 | ||
| - (decision) Product Brief 必须采用存量能力收束而非重造：将 OpenCLI 定义为分层的本地 Deep Research 数据上游——Acquisition Plane 负责实时多源采集，Evidence Plane 负责原始内容、逐源结果、lineage、版本与运行证据，Research Plane 负责问题拆解、检索编排、冲突/缺口识别与带引用综合，Consumption Plane 通过 MCP/SDK/API 向下游 Agent/系统交付。 | ||
| - (event) 发现两项方向冲突需在 Brief 中显式裁决：Issue #15 将产品扩展为数据采集、处理与外部交付平台，且要求全局 Agent Dock；当前用户将边界收窄为本地爬虫/数据上游并正在质疑独立 Agent Home。Issue #15 应作为历史产品证据，而非无条件继承的最新权威。 | ||
| - (assumption) 当前最大缺口不是来源数量或节点数量，而是尚未形成一条面向 Deep Research 的统一、可查询、可引用、可复现、可更新的 Source→Snapshot/Record→Transform→Claim/Citation→Research Output 源数据链；这一判断需要结合现有数据模型和用户确认继续验证。 | ||
|
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,37 @@ | ||
| --- | ||
| title: OpenCLI Agent-First Operations System | ||
| status: draft | ||
| created: 2026-08-24 | ||
| updated: 2026-08-24 | ||
| --- | ||
|
|
||
| # Product Brief: OpenCLI Agent-First Operations System | ||
|
|
||
| ## Executive Summary | ||
|
|
||
| 待通过产品发现补充。 | ||
|
|
||
| ## The Problem | ||
|
|
||
| 待通过产品发现补充。 | ||
|
|
||
| ## The Solution | ||
|
|
||
| 待通过产品发现补充。 | ||
|
|
||
| ## Who This Serves | ||
|
|
||
| 待通过产品发现补充。 | ||
|
|
||
| ## Success Criteria | ||
|
|
||
| 待通过产品发现补充。 | ||
|
|
||
| ## Scope | ||
|
|
||
| 待通过产品发现补充。 | ||
|
|
||
| ## Vision | ||
|
|
||
| 待通过产品发现补充。 | ||
|
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,41 @@ | ||
| --- | ||
| topic: OpenCLI Local Deep Research Data Upstream | ||
| updated: 2026-08-24T14:15 | ||
| --- | ||
|
|
||
| - (direction) Express distillation from the active Product Brief discovery, its canonical memlog, and first-party upstream Issues/PRs; unresolved product boundaries remain explicit. | ||
| - (decision) OpenCLI is a locally deployed, Agent-first crawler and Deep Research data upstream, not a SaaS work-deployment platform. | ||
| - (capability) CAP-1 Persistent Research Projects: an Agent or human can turn a research objective into one durable project whose workflow, sources, runs, evidence, and revisions survive sessions. | ||
| - (capability) CAP-2 Real-time Multi-source Acquisition: a project can continuously acquire current information through governed browser, web, API, RSS, and OpenCLI/plugin sources with per-source outcomes. | ||
| - (capability) CAP-3 Verifiable Source Chain: every research output can be traced through citations and claims to transformations, records or snapshots, source identity, acquisition run, workflow version, and timestamps. | ||
| - (capability) CAP-4 Deep Research Orchestration: the system can decompose a research objective, plan and execute multi-source retrieval, detect conflicts and evidence gaps, and produce a structured evidence-backed research output. | ||
| - (capability) CAP-5 Agent/System Consumption: downstream Agents and systems can discover capabilities and consume normalized records, evidence, provenance, run status, and research outputs through stable MCP, SDK, or HTTP contracts. | ||
| - (capability) CAP-6 Governed Reusable Extensions: source adapters, browser execution nodes, transforms, research operators, and sinks can be installed and published as versioned workflow/plugin capabilities with declared readiness and permissions. | ||
| - (capability) CAP-7 Local Deployment and Recovery: an operator can install, configure, run, observe, upgrade, and recover the complete platform locally without depending on an OpenCLI-hosted SaaS control plane. | ||
| - (capability) CAP-8 Unified Agent and Visual Editing: Agent interaction and manual UI operate the same authoritative project and workflow objects using proposals, revisions, validation, and durable execution evidence rather than chat-only shadow state. | ||
| - (constraint) Source-chain integrity is the highest-priority invariant; synthesis without resolvable citations and preserved raw evidence cannot be authoritative. | ||
| - (constraint) The system is local-first and self-hosted; hosted coordination may be optional but cannot be required for core acquisition, research, storage, or consumption. | ||
| - (constraint) Existing verified OpenCLI capabilities and merged contracts must be reused; catalog presence, previews, fixtures, and open PRs must not be represented as runnable production capability. | ||
| - (constraint) Agent and UI edits must converge on the same durable domain state; high-risk changes, credentials, publication, and external effects remain governed and auditable. | ||
| - (constraint) Plugins and workflows declare version, typed contracts, permissions, readiness, and failure semantics; unknown, stale, or unsafe capabilities fail closed. | ||
| - (decision) External business delivery and SaaS work orchestration are non-goals for the core product; downstream delivery is an optional plugin/consumer boundary. | ||
| - (decision) A generic chatbot, a generic low-code platform, an infrastructure topology product, and a UI that exposes the raw capability catalog as the primary experience are non-goals. | ||
| - (assumption) The spec assumes OpenCLI owns evidence-backed research outputs in addition to normalized evidence, pending explicit user confirmation of the synthesis boundary. | ||
| - (question) Must the first-party product produce final narrative research conclusions, or only structured evidence packages and citation graphs for downstream Agents to synthesize? | ||
| - (question) Should the primary Agent surface be a contextual global dock, a project-scoped workspace, or both, given the rejected standalone Agent Home and the older Issue #15 dock direction? | ||
| - (event) project-context.md was configured as a persistent fact but is absent; no facts were inferred from it. | ||
| - (event) Self-validation pass 1 (coherence): PASS — five kernel fields present; CAP-1 through CAP-8 are unique and each has one WHAT-level intent plus a demonstrable success criterion; constraints bend design; non-goals and a concrete end-to-end success signal are present; inferred boundaries are isolated as assumptions or questions. | ||
| - (event) Self-validation pass 2 (preservation): PASS — local-first crawler identity, persistent Agent projects, real-time acquisition, Deep Research, source-chain priority, downstream consumption, extensibility, deployment, existing merged foundations, open work, and Issue #15 boundary conflicts land in SPEC.md, brownfield.md, or source-chain.md. | ||
| - (event) Wrapper-only content dropped: empty Product Brief placeholder headings and workflow ceremony carry no load-bearing product contract. | ||
| - (direction) User separated two requirements: cross-device portability of previously authored projects/workflows is a product capability; administration of migration and related content belongs under Settings as a distinct information-architecture rule. | ||
| - (capability) CAP-9 Portable Project and Workflow Transfer: an operator can export a durable project or workflow from one OpenCLI instance and import it into another device or LAN deployment with preserved graph/version identity, explicit dependency preflight, connection remapping, and no secret leakage. | ||
| - (constraint) Settings is the authoritative administration surface for import/export, migration history, compatibility reports, dependency repair, connection remapping, backup, and restore; contextual project pages may link there but must not create a parallel migration authority. | ||
| - (question) Must a portable package support workflow-only transfer, full project transfer including records/evidence/run history, or both as explicit profiles? | ||
| - (event) Observed brownfield evidence on 2026-08-24: the Gaojixing project shell, one primary workflow, published v1, six runs, and 76 events exist in the current backend, but all runs are failed/blocked and the project has zero records, fields, and sources; the prior LAN migration is partial rather than complete. | ||
| - (event) Spec update self-validation pass 1 (coherence): PASS - CAP-9 is stable and unique, has one WHAT-level intent and a cross-instance demonstrable success criterion; Settings ownership is a separate design-bending constraint; all nine capabilities retain intent/success pairs. | ||
| - (event) Spec update self-validation pass 2 (preservation): PASS - the two user claims remain separate in SPEC.md and portability.md; current partial-migration evidence lands in brownfield.md; workflow portability, dependency preflight, secret exclusion, transactional import, Settings authority, and the unresolved historical-data profile are preserved. | ||
| - (decision) CAP-9 supports both explicit profiles: Workflow Package for reusable workflow definitions and dependency manifests, and Full Project Package for project metadata plus workflows, source descriptors, records, evidence, artifacts, run history, and audit provenance; neither profile contains reusable secrets or host-bound execution grants. | ||
| - (decision) The earlier portability-profile question is resolved: both profiles are mandatory first-class contracts, selected explicitly during export and verified independently during import. | ||
| - (event) Spec update self-validation pass 1 (coherence): PASS - CAP-9 remains one stable capability with both mandatory profiles named in its success criterion; the resolved profile question was removed; all nine capabilities retain complete intent/success pairs. | ||
| - (event) Spec update self-validation pass 2 (preservation): PASS - Workflow Package preserves reusable design and dependency contracts; Full Project Package preserves project state, records, evidence, artifacts, lineage, runs, events, checkpoints, and audit history; both exclude secrets and have independent conformance journeys. | ||
|
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,90 @@ | ||
| --- | ||
| id: SPEC-opencli-Razormind | ||
| companions: | ||
| - brownfield.md | ||
| - portability.md | ||
| - source-chain.md | ||
| sources: | ||
| - ../../planning-artifacts/briefs/brief-opencli-Razormind-2026-08-24/brief.md | ||
| --- | ||
|
|
||
| > **Canonical contract.** This SPEC and the files in `companions:` are the complete, preservation-validated contract for what to build, test, and validate. Source documents listed in frontmatter are for traceability only. | ||
|
|
||
| # OpenCLI Local Deep Research Data Upstream | ||
|
|
||
| ## Why | ||
|
|
||
| Researchers and downstream Agents need current information, but heterogeneous sources, fragile acquisition, fragmented provenance, and chat-only automation make research difficult to reproduce or reuse. OpenCLI already contains substantial acquisition, workflow, evidence, Agent-control, and self-hosting foundations. The work is to converge them into a local-first Deep Research upstream whose intelligence is grounded in a durable source chain rather than rebuild another crawler UI or SaaS operations platform. | ||
|
|
||
| ## Capabilities | ||
|
|
||
| - **CAP-1 — Persistent Research Projects** | ||
| - **intent:** An Agent or human can turn a research objective into one durable project containing its workflow, sources, runs, evidence, and revisions. | ||
| - **success:** After restart or session change, the project can resume from its persisted state and every run resolves to the project and exact workflow revision that produced it. | ||
|
|
||
| - **CAP-2 — Real-time Multi-source Acquisition** | ||
| - **intent:** A project can continuously acquire current information through governed browser, web, API, RSS, and OpenCLI/plugin sources. | ||
| - **success:** A live mixed-source run records an outcome for every configured source, preserves successful results during partial failure, and reports blocked or failed sources without claiming completeness. | ||
|
|
||
| - **CAP-3 — Verifiable Source Chain** | ||
| - **intent:** A consumer can trace every research claim and citation back through transformations to preserved source material and acquisition context. | ||
| - **success:** Given any published research claim, an API query resolves its citation, transformed record, raw snapshot or artifact, source identity, acquisition timestamp, run, and workflow version; any missing link makes the claim non-authoritative. | ||
|
|
||
| - **CAP-4 — Deep Research Orchestration** | ||
| - **intent:** The system can decompose a research objective, coordinate multi-source retrieval, identify conflicts and evidence gaps, and produce a structured evidence-backed research output. | ||
| - **success:** A reference research task produces a persisted plan, source-backed findings, explicit conflicts and unresolved gaps, and citations that pass CAP-3 trace verification. | ||
|
|
||
| - **CAP-5 — Agent and System Consumption** | ||
| - **intent:** Downstream Agents and systems can discover capabilities and consume normalized records, evidence, provenance, run state, and research outputs through stable machine contracts. | ||
| - **success:** An external Agent completes the reference research journey through MCP or HTTP without scraping the UI, and receives versioned schemas plus stable identifiers shared with the first-party interface. | ||
|
|
||
| - **CAP-6 — Governed Reusable Extensions** | ||
| - **intent:** Operators can install and reuse versioned source adapters, browser nodes, transforms, research operators, and optional sinks as workflow/plugin capabilities. | ||
| - **success:** A certified extension declares typed inputs and outputs, version, readiness, permissions, and failure semantics; it compiles and runs when ready, while forged, stale, unverified, or unsafe capabilities fail closed. | ||
|
Comment on lines
+41
to
+43
There was a problem hiding this comment. 🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win 🧩 Analysis chain🏁 Script executed: #!/bin/bash
set -e
printf '%s\n' '--- candidate files ---'
git ls-files | rg '(^|/)(SPEC|spec|contract|contracts|requirements|README|readme|.*CAP.*|.*cap.*)' | head -200
printf '%s\n' '--- target directory ---'
find _bmad-output/specs/spec-opencli-Razormind -maxdepth 2 -type f -print 2>/dev/null | sort
printf '%s\n' '--- trust-related references ---'
rg -n -i -C 3 'authentic|integrity|revok|trust|certif|signature|signed|forged|stale|unverif|unsafe|conformance|fail closed|extension|capabilit' _bmad-output/specs/spec-opencli-Razormind 2>/dev/nullRepository: 2233admin/opencli-Razormind Length of output: 26769 🏁 Script executed: #!/bin/bash
set -e
printf '%s\n' '--- relevant companion sections ---'
cat -n _bmad-output/specs/spec-opencli-Razormind/portability.md | sed -n '1,95p'
printf '%s\n' '--- certified capability references across the repository ---'
rg -n -i -C 4 'stale.*forged|forged.*stale|stale.*ID|forged.*ID|version pin|version-pin|certificate|signature|revocation|revoked|trust|integrity manifest|conformance' \
backend docs openspec tests _bmad-output/specs/spec-opencli-Razormind 2>/dev/null
printf '%s\n' '--- likely implementation contracts ---'
for f in backend/workflow/conformance/contracts.py backend/plugins/capability_catalog.py backend/workflow/capability_projection.py docs/verification/capability-provider-action-contract.md; do
if [ -f "$f" ]; then
echo "### $f"
cat -n "$f" | sed -n '1,240p'
fi
doneRepository: 2233admin/opencli-Razormind Length of output: 50384 🏁 Script executed: #!/bin/bash
set -e
printf '%s\n' '--- SPEC companion portability contract ---'
cat -n _bmad-output/specs/spec-opencli-Razormind/portability.md | sed -n '1,95p'
printf '%s\n' '--- capability trust terms in focused files ---'
rg -n -i -C 2 'authentic|integrity|revok|signature|signed|forged|stale|unverif|unsafe|conformance' \
_bmad-output/specs/spec-opencli-Razormind \
backend/plugins backend/workflow/conformance backend/workflow/capability_projection.py \
docs/verification docs/adr/0020-pin-capability-versions-in-executable-definitions.md \
docs/adr/0042-expose-capabilities-through-an-api-first-agent-loop.md \
tests/unit/test_capability_exposure_matrix.py \
tests/integration/test_plugin_capability_catalog_api.py \
tests/integration/test_workflow_capabilities_api.py 2>/dev/null | head -1200
printf '%s\n' '--- files mentioning certified capability nodes or PR 49 ---'
rg -l -i 'certified capability|PR `#49`|forged.*capability|stale.*capability|capability.*pin' . \
-g '!*.lock' -g '!*.json' -g '!frontend/lib/plugins/generated-capability-catalog.json' 2>/dev/null | sortRepository: 2233admin/opencli-Razormind Length of output: 34355 🏁 Script executed: #!/bin/bash
set -e
for f in backend/workflow/capability_projection.py backend/workflow/compiler.py backend/plan_ir/validation.py backend/schemas/workflow.py backend/workflow/runtime_registry.py backend/workflow/tool_capabilities.py; do
if [ -f "$f" ]; then
echo "### $f"
rg -n -C 5 'capabil|version|pin|readiness|permission|unsafe|stale|forged|registry|digest|hash|signature|certificate|revok' "$f" | head -260
fi
done
printf '%s\n' '--- capability-related tests ---'
rg -n -C 5 'capabil|version|pin|readiness|permission|unsafe|stale|forged|unknown|fail.closed|conformance' \
tests/unit/test_capability_exposure_matrix.py \
tests/unit/test_workflow_tool_catalog_projection.py \
tests/integration/test_workflow_capabilities_api.py \
tests/integration/test_plans_api.py \
tests/integration/test_workflow_patch_api.py 2>/dev/null | head -900
printf '%s\n' '--- relevant ADR and baseline text ---'
cat -n docs/adr/0020-pin-capability-versions-in-executable-definitions.md
cat -n _bmad-output/specs/spec-opencli-Razormind/brownfield.md | sed -n '1,60p'Repository: 2233admin/opencli-Razormind Length of output: 50384 🏁 Script executed: #!/bin/bash
set -e
printf '%s\n' '--- tool capability contract ---'
cat -n backend/workflow/tool_capabilities.py | sed -n '1,180p'
printf '%s\n' '--- external capability runtime resolution ---'
cat -n backend/workflow/runtime_registry.py | sed -n '735,850p'
printf '%s\n' '--- capability pin and rejection tests ---'
rg -n -C 8 'validate_workflow_tool_capability_version_pin|disallowed_tool_capability_provenance|tool_capability_version_pin_mismatch|unknown_tool_capability|forged|stale|versionPin' \
tests backend | head -1000
printf '%s\n' '--- all local references to trust properties ---'
rg -n -i -C 3 'authenticity|integrity|revocation|revoked|signature|attest|provenance|unverified|unsafe capability' \
backend docs tests _bmad-output/specs/spec-opencli-Razormind \
-g '*.py' -g '*.md' -g '*.yaml' -g '*.yml' | head -1200Repository: 2233admin/opencli-Razormind Length of output: 50384 🌐 Web query:
💡 Result: There is no evidence in the GitHub repository 2233admin/opencli-Razormind or elsewhere of a pull request Citations:
🏁 Script executed: #!/bin/bash
set -e
python3 - <<'PY'
from pathlib import Path
import re
paths = [
Path("_bmad-output/specs/spec-opencli-Razormind/SPEC.md"),
Path("_bmad-output/specs/spec-opencli-Razormind/portability.md"),
Path("_bmad-output/specs/spec-opencli-Razormind/source-chain.md"),
Path("_bmad-output/specs/spec-opencli-Razormind/brownfield.md"),
]
terms = {
"authenticity": r"\bauthentic(?:ity|ated)?\b",
"integrity": r"\bintegrity\b",
"revocation": r"\brevok(?:e|ed|ation)\b",
"signature": r"\bsign(?:ature|ed)\b",
"conformance": r"\bconformance\b",
"forged": r"\bforged\b",
"stale": r"\bstale\b",
"unverified": r"\bunverified\b",
}
for path in paths:
text = path.read_text()
print(f"### {path}")
for name, pattern in terms.items():
matches = [i + 1 for i, line in enumerate(text.splitlines())
if re.search(pattern, line, re.I)]
if matches:
print(f"{name}: {matches}")
for i, line in enumerate(text.splitlines(), 1):
if re.search(r"conformance|integrity|revok|authentic|signature|forged|stale|unverified|unsafe", line, re.I):
print(f"{i}: {line}")
PY
printf '%s\n' '--- exact authoritative capability tests ---'
cat -n tests/integration/test_plans_api.py | sed -n '145,240p'
printf '%s\n' '--- conformance case identifiers ---'
rg -n -C 2 'ConformanceCaseResult|case_results|evidenceCases|capability|tool' \
tests/integration/test_workflow_conformance.py \
tests/fixtures/workflow_conformance.py \
backend/workflow/conformance 2>/dev/null | head -500Repository: 2233admin/opencli-Razormind Length of output: 16223 Define the trust contract for certified capabilities. CAP-6 requires forged, stale, unverified, and unsafe capabilities to fail closed. The companion contracts define package integrity and stale or unsafe import handling, but they do not define capability authenticity, integrity verification, revocation, or executable trust-conformance cases. Specify the authoritative trust source and verification rules, then add cases for forged, stale, unverified, and unsafe capabilities. 🤖 Prompt for AI Agents |
||
|
|
||
| - **CAP-7 — Local Deployment and Recovery** | ||
| - **intent:** An operator can install, configure, run, observe, upgrade, and recover the complete platform on local infrastructure. | ||
| - **success:** A clean supported host passes an authenticated install-and-run smoke journey, executes the reference research task, retains data across restart, and restores operation without an OpenCLI-hosted SaaS dependency. | ||
|
Comment on lines
+45
to
+47
There was a problem hiding this comment. 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win Include upgrade and observation in CAP-7 success. The intent includes installation, configuration, observation, upgrade, and recovery. The success criterion covers installation, execution, restart persistence, and restore, but it does not verify upgrade or observation. Add assertions for a supported upgrade and observable run or status evidence, or narrow the intent. 🤖 Prompt for AI Agents |
||
|
|
||
| - **CAP-8 — Unified Agent and Visual Editing** | ||
| - **intent:** Agent interaction and manual UI operate the same authoritative project and workflow state without chat-only shadow objects. | ||
| - **success:** Agent and human edits carry base revisions and concrete diffs; non-conflicting changes preserve both edits, conflicting or stale changes cannot overwrite newer state, and accepted changes appear identically through UI and API. | ||
|
|
||
| - **CAP-9 — Portable Project and Workflow Transfer** | ||
| - **intent:** An operator can move a previously authored project or workflow between OpenCLI instances, devices, and LAN deployments without rebuilding it manually. | ||
| - **success:** Both a Workflow Package and a Full Project Package export from instance A import into a clean instance B with their profile-specific content preserved, produce explicit compatibility and missing-dependency reports, expose connection remapping without exporting secrets, and pass their independent conformance journeys after reported gaps are repaired. | ||
|
|
||
| ## Constraints | ||
|
|
||
| - Source-chain integrity is the highest-priority invariant: synthesis without resolvable citations and preserved source evidence cannot be authoritative. | ||
| - Core acquisition, research, storage, and consumption must run locally; hosted coordination may be optional but cannot be required. | ||
| - Reuse merged and verified OpenCLI contracts. Catalog entries, previews, fixtures, open Issues, and open PRs must not be presented as production capability. | ||
| - Agent and UI operations share durable domain state. Credentials, publication, destructive changes, permission changes, and external side effects remain governed and auditable. | ||
| - Plugins and workflows declare versions, typed contracts, permissions, readiness, and failure semantics. Unknown, stale, unavailable, or unsafe capability bindings fail closed. | ||
| - Raw evidence and lineage survive cleaning, merging, retries, partial failure, workflow publication, and downstream export. | ||
| - Settings is the authoritative administration surface for import/export, migration history, compatibility reports, dependency repair, connection remapping, backup, and restore. Project pages may link into that surface but cannot create a parallel migration authority. | ||
|
|
||
| ## Non-goals | ||
|
|
||
| - Operating a SaaS work-deployment or hosted data-processing platform. | ||
| - Becoming a generic chatbot, generic low-code builder, or infrastructure-topology product. | ||
| - Making external business delivery the core workflow; delivery remains an optional plugin or downstream consumer boundary. | ||
| - Treating the number of adapters, nodes, or catalog entries as proof of research quality. | ||
| - Recreating existing verified acquisition, workflow, MCP, evidence, or installation foundations under a parallel abstraction. | ||
| - Requiring operators to copy databases, edit package internals, recreate graphs, or transfer reusable credentials manually to move work between supported instances. | ||
|
|
||
| ## Success signal | ||
|
|
||
| From a fresh local installation, an operator imports a project or workflow from another supported OpenCLI instance, resolves the reported local dependencies in Settings, and runs a persistent research project that acquires live multi-source information, produces a structured output with claim-level citations, and lets an external Agent traverse every citation to preserved source evidence through MCP or HTTP. Restarting or rerunning does not lose state or silently change the executed workflow version. | ||
|
Comment on lines
+76
to
+78
There was a problem hiding this comment. 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win Separate the two portability success journeys. CAP-9 defines Workflow Package and Full Project Package profiles, but the success signal says “imports a project or workflow” and then requires a persistent research project. A Workflow Package is reusable workflow content, not necessarily project state. State the required create-and-attach step for workflow-only imports, or define separate success signals for the two profiles. 🤖 Prompt for AI Agents |
||
|
|
||
| ## Assumptions | ||
|
|
||
| - OpenCLI owns evidence-backed research outputs in addition to normalized evidence; the exact narrative-synthesis boundary still needs confirmation. | ||
| - OpenCLI and CloseI alignment means compatible capability and consumption contracts, not merging their product identities. | ||
|
|
||
| ## Open Questions | ||
|
|
||
| - Must the first-party product produce final narrative conclusions, or only structured evidence packages and citation graphs for downstream Agents to synthesize? | ||
| - Should the primary Agent surface be a contextual global dock, a project-scoped workspace, or both? | ||
| - Which benchmark research journey and source set will be the release-level conformance test for CAP-1 through CAP-9? | ||
|
|
||
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Test the continuous part of CAP-2.
The intent requires continuous acquisition of current information, but the success criterion validates only one live mixed-source run. Add repeated or scheduled acquisition with a freshness assertion while retaining the partial-failure checks. Otherwise, a one-shot runner can satisfy CAP-2.
🤖 Prompt for AI Agents