v0.3.4 — First Value & Unified Operations

v0.3.4 — First Value & Unified Operations

v0.3.4 makes ResolveWeave useful immediately after installation. A fresh
administrator can explicitly install a small bilingual demo pack, ask a guided
question through the existing chat contract, inspect the document source, and
complete onboarding without a paid model key. A new Operations page then
provides one bounded view of runtime configuration, work queues, and recent
failures.

First value

• Fresh databases redirect the first admin login to /admin/getting-started;
  upgraded databases are classified as legacy and are not interrupted.
• sample-pack-v1 contains three Chinese/English FAQ pairs and one bilingual
  Markdown return policy. Every item is visibly marked as demo data.
• Installation is explicit, idempotent, safe under concurrent replay, and
  retryable after document-processing failure without duplicate knowledge.
• The recommended Chinese and English questions must produce sufficient
  grounding with the sample Markdown document in the persisted source list.
• The server, not the browser, verifies the answer and source before recording
  first value. Onboarding sessions do not affect customer session,
  satisfaction, or escalation analytics.
• db:seed now synchronizes only the deployment-managed administrator; it no
  longer writes demo FAQ records.

Unified operations

• /admin/operations summarizes SQLite, deterministic/model answer mode,
  embeddings, optional Qdrant and OCR, queue counts, and a bounded list of
  recent document, quality, index, OCR, and trace problems.
• The no-key deterministic path is healthy. Optional infrastructure that is
  not configured is shown as optional-disabled rather than failed.
• The overview does not call an LLM provider. Model cards report configuration
  readiness and do not promise live health or create hidden usage.
• Operators may retry a failed document through the existing document API or
  idempotently create a new failed-quality-run rerun with the original inputs.
• Index build/activation/rollback and OCR review remain deep links to their
  owner workbenches; v0.3.4 adds no fake pause/resume controls.

Admin experience

• The desktop sidebar keeps its existing structure.
• At mobile width it becomes a keyboard-closeable TDesign Drawer with complete
  Chinese/English labels and 44px targets, fixing truncated navigation text.
• Getting Started and Operations support Chinese/English copy, light/dark
  themes, loading, empty, error, optional-disabled, degraded, failed, and
  recovery states.

Compatibility and non-goals

• POST /api/chat adds only optional onboardingRunId; existing SSE event
  names, fields, and ordinary-client behavior remain compatible.
• SQLite migrations are additive and idempotent. Historical sessions migrate
  to customer origin and existing analytics remain unchanged.
• This release does not add Agentic Retrieval, business tools, multi-tenancy,
  external telemetry, or a general task orchestrator.

See v0.3.4 release evidence for measurements, test gates,
screenshots, and known limits.

---

中文说明

v0.3.4 让 ResolveWeave 在安装后立即产生可验证价值：全新数据库首次登录进入
独立引导，管理员显式加载 sample-pack-v1，在无付费模型 Key 路径提出中英文
推荐问题，得到带双语 Markdown 文档来源的回答并完成来源检查。升级数据库标记
为 legacy，不会被强制跳转；引导会话也不进入普通会话、满意度或转人工统计。

新的“运行中心”统一展示 SQLite、回答模式、Embedding、可选 Qdrant/OCR、任务
计数和有界近期问题。它不会后台探测 LLM 或产生隐藏费用，只集中失败文档重试
和失败质量任务幂等重跑。索引激活/回滚与 OCR 复核仍回到原工作台执行。

移动端后台改为完整标签、44px 点击目标且可用 ESC 关闭的 TDesign Drawer。
本版本不加入 Agentic Retrieval、业务工具、多租户、外部遥测或通用任务编排。

v0.3.3 — Security Hardening

v0.3.3 — Security Hardening

v0.3.3 hardens the deployment, provider, public API, browser rendering, export,
analytics, streaming, and OCR boundaries identified by an OpenAI Codex Security
review of v0.3.2. It does not change the chat SSE event contract, SQLite as the
system of record, or the no-model-key local fallback.

Security outcome

• Docker Compose requires explicit JWT/admin secrets and binds application
  ports to loopback. Seeding transactionally synchronizes the single
  environment-managed administrator, including username/password changes and
  cleanup of stale privileged rows from earlier starts.
• Model API Base URLs are deployment-owned and read-only to admins. Credentials
  are shared between chat and embedding clients only for the same normalized
  endpoint.
• Chat, login, admin, and public FAQ search limits use IPv6-aware subnet keys.
  Semantic FAQ search also has a separate concurrency limit, bounded input,
  bounded result count, and a public DTO without embedding or operator fields.
• CSV exports neutralize spreadsheet formulas. Markdown rendering drops images
  so untrusted answers cannot trigger third-party browser requests.
• LLM streams have a UTF-8 byte cap and a single application buffer. Dashboard
  overview metrics aggregate directly in SQLite instead of expanding a session
  ID into one bind parameter per row.
• The OCR worker requires a bearer token, compares it in constant time, limits
  PDF pages and image pixels/dimensions, permits one in-flight extraction, and
  bounds processing time and provider/final result sizes. A native inference
  timeout forces worker-process exit; the supported Compose profile restarts
  it with clean state.
• The unused vulnerable xlsx package was removed. bcrypt, uuid, and
  express-rate-limit were upgraded; React Router was upgraded to the newest
  release that fixes the SPA-reachable redirect issues.

Compatibility and limits

• Admins can still change provider and model names, but must change API Base
  URLs through deployment configuration.
• Compose must now be given JWT_SECRET and ADMIN_PASSWORD; the OCR profile
  additionally requires OCR_SERVICE_TOKEN.
• Public FAQ list responses intentionally omit operational timestamps,
  embedding metadata, activation state, and updater identity.
• The remaining npm advisory affects React Router RSC/server-action mode. This
  project is a Vite BrowserRouter SPA and does not use React Router RSC,
  actions, loaders, SSR, or server hydration; see the evidence file.

See v0.3.3 implementation evidence for verification and
the residual-risk record.

---

中文说明

v0.3.3 针对 v0.3.2 的 OpenAI Codex Security 审查结果，收紧部署 Secret、
模型端点与凭据边界、公共 FAQ 资源上限、CSV/Markdown 输出、流式回答、统计
查询和 OCR Worker。聊天 SSE 事件、SQLite 权威数据源以及无模型 Key 的本地
回退路径保持兼容。

Compose 现在必须显式提供 JWT 与管理员密码，应用端口默认只绑定本机；模型
API Base URL 只能通过部署环境修改；IPv6 限流按子网归一，公共语义检索另有
并发上限；公开 FAQ 不再泄漏 embedding、更新时间或操作人；CSV 会中和公式，
Markdown 不加载外链图片；LLM 流和 OCR 输入、执行与输出均增加硬上限。

OCR profile 现在必须提供 OCR_SERVICE_TOKEN。剩余 npm 告警只涉及本项目未
使用的 React Router RSC/server-action 模式，具体可达性判断见验证证据。
管理员环境用户名或密码变更会同步到唯一管理员并清理遗留账号；OCR 原生推理
超时后会强制退出 Worker 进程，由 Compose 监督重启，避免单槽永久占用。

v0.3.2 — Qdrant & Retrieval Observability

v0.3.2 — Qdrant & Retrieval Observability

v0.3.2 adds an optional production-oriented Qdrant vector backend and a
retrieval operations loop without changing the fresh-clone default. SQLite
remains the knowledge system of record, the in-memory index remains the
zero-infrastructure default, and the existing chat SSE contract is unchanged.

Product outcome

Administrators now have a bilingual Retrieval Operations workspace where
they can:

• inspect the configured backend, Qdrant health, active alias/collection,
  vector count, dimension, and synchronization state;
• build a versioned Qdrant collection from current SQLite knowledge and resume
  an interrupted job when its knowledge fingerprint is unchanged;
• compare memory and a ready Qdrant index in Quality Lab with the same dataset,
  policy, and query embeddings;
• activate an eligible collection through an atomic alias switch, explicitly
  acknowledge a P95 latency warning above 25%, and roll the alias back to the
  previous verified collection;
• filter retrieval traces and inspect the fixed eight-stage timeline without
  storing duplicate customer questions or knowledge content.

Engineering boundary

• VectorStore is asynchronous. InMemoryVectorStore preserves the local
  path; QdrantVectorStore uses @qdrant/js-client-rest 1.18.0.
• Qdrant point IDs are stable UUIDv5 values. Payloads contain only knowledge
  ID, knowledge type, version, and embedding profile.
• Qdrant candidates are batch-hydrated from SQLite and rejected when the
  knowledge is missing, disabled, stale, or attached to an inactive source.
• Qdrant timeout or unavailability produces a degraded trace and keeps
  keyword/structured recall available. It never silently rebuilds an
  in-memory vector index.
• Index jobs use fixed states and checkpoints. Readiness verifies profile,
  dimension, point count, and the current knowledge fingerprint.
• Activation and rollback require idempotency keys and expected-current
  collection values. Old collections are not automatically deleted.
• Retrieval traces retain safe stage metadata for 30 days by default, cascade
  with deleted sessions, and are cleaned at startup and daily.

Running Qdrant

The default command still starts the memory-backed application:

docker compose up --build

Start the pinned Qdrant 1.18.2 Compose profile and select it at deployment
time:

VECTOR_STORE_PROVIDER=qdrant \
QDRANT_URL=http://qdrant:6333 \
docker compose --profile qdrant up --build

Changing VECTOR_STORE_PROVIDER requires an application restart. The admin
workspace can switch the configured collection alias, but it cannot change
infrastructure credentials or the primary backend.

Non-goals and limits

This release does not add runtime memory/Qdrant switching, automatic backend
failover, production-traffic shadow queries, Qdrant sparse/hybrid retrieval,
snapshots, clustering, automatic old-collection deletion, OpenTelemetry, or
Agentic Retrieval.

See v0.3.2 implementation evidence for the verification
matrix, screenshots, benchmark results, and local environment limitation.

---

中文说明

v0.3.2 在不改变 fresh-clone 默认行为、SQLite 权威数据源和聊天 SSE 契约的
前提下，增加可选生产向 Qdrant 向量后端与完整检索运维闭环。

管理员可以在独立的双语“检索运维”页面查看后端健康、alias/collection、
点数、维度和同步状态；从 SQLite 构建可恢复的版本化索引；在 Quality Lab
中用同一数据集、策略和查询 embedding 对比 memory/Qdrant；通过质量门禁后
原子激活 alias，并在需要时回滚到上一已验证 collection；还可以按状态、后端、
会话和时间筛选检索 Trace，查看固定八阶段时间线。

Qdrant 命中必须回查 SQLite，孤儿、旧版本、停用知识或失效来源不会成为证据。
Qdrant 超时或不可用时会记录 degraded Trace，并继续关键词/结构化检索，
不会静默重建内存向量。部署配置决定主后端并在重启后生效；后台只能切换
collection alias，不能修改凭据或运行时切换后端。

本版本不包含自动 failover、真实客服流量影子查询、Qdrant sparse/hybrid、
快照/集群、旧 collection 自动清理、OpenTelemetry 或 Agentic Retrieval。

v0.3.1 — Multimodal Knowledge Review

v0.3.1 — Multimodal Knowledge Review

v0.3.1 adds a reviewed OCR ingestion path without changing the existing
FAQ/text-document or chat compatibility surfaces.

Product outcome

Administrators can upload PNG, JPEG, WebP, and scan-only PDF knowledge sources.
The source is stored privately, a durable extraction job is queued, and
PaddleOCR PP-StructureV3 produces immutable structured Blocks. The result is
never searchable automatically: an administrator reviews and edits a
revisioned draft, then publishes the complete document atomically.

The existing Documents page now exposes:

• queued, running, completed, and failed extraction states;
• authoritative engine/version, safe errors, attempts, retry relationships,
  and timestamps;
• ordered Block review with page, confidence, layout, structure, and manual
  edit state;
• optional DeepSeek-OCR-2 shadow status and text/structure agreement;
• published citation provenance down to page, source Blocks, extraction job,
  and engine version.

Engineering boundary

• PaddleOCR PP-StructureV3 is the only authoritative extractor.
• DeepSeek-OCR-2 is optional comparison-only output. It cannot create,
  overwrite, or publish a review draft.
• SQLite stores durable extraction jobs and revisioned drafts additively.
  Interrupted running jobs return to queued when the scheduler starts.
• The Node service and external worker communicate through bounded,
  project-owned request/result schemas. Both boundaries verify source size,
  type, signature, and SHA-256; worker output is schema-validated before it is
  persisted.
• Publication re-runs DocumentIR validation, cleaning, quality gates,
  structure-aware chunking, embedding, and index consistency against the whole
  reviewed draft.
• Existing FAQ, TXT/Markdown/text-PDF/DOCX, SQLite, in-memory VectorStore,
  no-key, admin API, and chat SSE behavior remain compatible.

Local worker

The optional CPU worker lives in ocr-worker/.
It follows PaddleOCR's PP-StructureV3 pipeline and maps layout, OCR lines, and
tables into the same versioned Block contract used by text documents.

OCR_SERVICE_URL=http://ocr-worker:8001 \
  docker compose --profile ocr up --build

The first start downloads Paddle models. Existing capabilities continue to run
when no OCR worker is configured. The worker pins PaddleOCR and PaddleX to
3.0.3; this matching pair is required for PP-StructureV3 initialization.

Non-goals and limits

This release does not add free-form VLM answers over raw images, multimodal
embeddings, Qdrant, distributed queues, web ingestion, domain-specific field
automation, or business tools. OCR confidence remains extraction evidence, not
answer confidence; the existing Grounding Gate still decides whether retrieved
knowledge can support a response.

See v0.3.1 implementation evidence for verification and
known deployment risks.

---

中文说明

v0.3.1 在不改变 FAQ、文本文档和聊天兼容接口的前提下，新增“先 OCR、后复核、
再整文档发布”的知识入库路径。

管理员可以上传 PNG、JPEG、WebP 和扫描 PDF。原文件会私有保存，SQLite
持久化任务队列把文件交给权威 PaddleOCR PP-StructureV3 Worker；识别结果先
保存为不可变输出和可编辑的版本化复核草稿，管理员确认整份文档后才会原子
发布并进入检索。

文档详情可检查任务状态、引擎版本、安全错误、重试关系、Block 的页码/置信度/
布局和编辑状态，以及可选 DeepSeek-OCR-2 影子结果的一致度。发布后的来源会
保留文档、页码、Block、提取任务和 OCR 引擎版本。

Paddle 是唯一权威结果；DeepSeek 只能对照，不能覆盖或自动发布。没有配置
OCR Worker 时，原有 FAQ、TXT/Markdown/文本 PDF/DOCX 和无 Key 路径继续
运行。本版本不包含原图自由视觉问答、多模态 embedding、Qdrant、分布式队列、
网页采集、领域字段自动化或业务工具。

v0.3.0 — Structure-Aware Ingestion Foundation

v0.3.0 — Structure-Aware Ingestion Foundation

v0.3.0 replaces format-specific “extract text and chunk immediately” behavior
with one versioned, inspectable ingestion boundary:

validate → parse → normalize → clean → quality_gate → chunk → embed → publish

Product outcome

Administrators continue uploading TXT, Markdown, text-layer PDF, and DOCX from
the existing Documents page. The system now preserves the structure it can
reliably extract, records why content was accepted or withheld, and exposes
safe processing evidence without returning file paths or embeddings.

The document detail shows:

• quality and index status;
• parser, representation, cleaner, and chunker versions;
• structure counts and parser/cleaner warnings;
• a paginated Block inspector with type, heading path, page, content preview,
  inclusion state, and source relationship;
• the fixed eight-stage processing timeline;
• published chunks with heading/page provenance.

Engineering boundary

• DocumentIR v1 is Zod-validated, limited to 2 MiB and 2,000 ordered Blocks.
• TXT retains paragraphs; Markdown retains heading hierarchy, lists, and fenced
  code; text PDF retains page numbers and deterministic page order; DOCX
  retains reliably extracted headings, paragraphs, lists, tables, and image
  references.
• Scan-only PDFs and image-only DOCX content return review-required quality
  results. v0.3.0 does not fabricate OCR or visual descriptions.
• Cleaning is deterministic. PDF headers or footers are excluded only when the
  same short Block appears in the same first/last page position on at least
  three pages and at least 60% of pages.
• Lists remain item-boundary aware. Tables repeat the extracted header when
  rows require multiple chunks. Paragraphs continue using semantic chunking.
• New uploads do not expose chunks until every pre-publication stage succeeds.
  Explicit legacy reprocessing uses a shadow build; failed publication restores
  the previous database state and reconciles the in-memory index.
• SQLite remains the default store and the current VectorStore, hybrid
  retrieval, FAQ, SSE, Grounding, and no-key contracts remain compatible.

API additions

• GET /api/admin/documents/:id adds optional representation, quality, index,
  and processing summaries.
• GET /api/admin/documents/:id/blocks?page=1&pageSize=20 returns safe,
  paginated Block DTOs.
• POST /api/admin/documents/:id/reprocess explicitly upgrades a published
  legacy document; an already-current successful result is reused.
• Existing upload, list, chunk, retry, enable/disable, delete, chat, and SSE
  interfaces remain available.

Non-goals and limits

OCR/VLM execution, Qdrant, Agentic Retrieval, business tools, domain-specific
field extraction, manual force-publish, background workers, and scheduled
reprocessing are not included. See
v0.3.0 implementation evidence for the current
verification state and ROADMAP.md for the next releases.

---

中文说明

v0.3.0 将原来的“按格式提取文本后直接切片”升级为统一、版本化且可检查的入库
管线。管理员仍在原有“文档知识”页面上传 TXT、Markdown、含文本层 PDF 和
DOCX；详情中可以检查质量/索引状态、各处理版本、结构统计、警告、分页 Block、
八阶段时间线和已发布切片。

DocumentIR v1 保留可靠提取到的标题、段落、列表、表格、页码、顺序与图片
引用。扫描 PDF 和仅图片 DOCX 会进入复核且不建立索引，系统不会伪造 OCR
结果。新上传只有在全部阶段成功后才可检索；历史 ready 文档使用影子重处理，
发布失败时恢复旧数据库状态并同步内存索引。

本版本继续使用 SQLite、现有 VectorStore、混合检索和无 Key 路径；不包含
OCR/VLM、Qdrant、Agentic Retrieval、业务工具、人工强制放行、后台 Worker 或
定时重处理。

v0.2.9 Structured Escalation & Triage

v0.2.9 — Structured Escalation & Triage

v0.2.9 upgrades free-text escalation records into traceable handoff packets and
adds a read-only bilingual triage console. The release preserves the public chat
request and SSE contracts, anonymous conversation ownership, SQLite deployment,
and the no-key local path.

Product outcome

When chat requires a human, the system now persists:

• a concise summary and reason code;
• a deterministic category, priority, risk set, recommended queue, and next
  step;
• facts tied to existing message IDs and verbatim excerpts;
• missing-information prompts and retrieval evidence;
• the extraction mode and versioned rule/schema identifiers.

Admins can filter the latest escalation per conversation by status, category,
priority, queue, and keyword, then open the packet to locate cited messages and
retrieval evidence.

Deterministic safety boundary

triage_v1 gives account security, unauthorized transactions, and immediate
safety risk urgent priority. Knowledge conflicts, private-state business
operations, and material complaints are high priority. All other supported
handoffs remain normal priority.

Optional model extraction shares a two-second total budget and negotiates
json_schema, json_object, then plain-text JSON without retrying a format.
The model can propose only the summary, cited facts, and missing information.
Invalid JSON, protected fields, timeouts, or missing credentials return the
complete deterministic packet. The extractor receives only the latest 12
messages; facts with unknown message IDs or non-verbatim excerpts are discarded
individually without weakening deterministic routing.

Conversation and retrieval text is placed in the prompt as untrusted data and
cannot override deterministic routing.

Persistence and compatibility

The additive escalation_packets table is one-to-one with escalation_log and
keeps filterable scalar fields separate from validated JSON collections. Startup
backfills historical rows idempotently as:

category = unknown
priority = normal
recommended_queue = manual_triage
extraction_mode = legacy_unstructured

Historical rows do not receive invented facts. New chat escalations save the
assistant message, escalation log, packet, and escalated session state in one
SQLite transaction. A packet failure rolls the whole state change back.

Existing intent, faq, token, escalate, done, and error SSE events are
unchanged. ConversationDetail.escalation.packet is optional, so old clients can
continue reading the legacy escalation fields.

New read-only APIs

GET /api/admin/escalations
GET /api/admin/escalations/:escalationId

Both routes require the existing administrator authentication and response
envelope. The list supports bounded pagination plus status, category, priority,
queue, and escaped keyword filters. No assignment, notes, takeover, resolution,
or other mutation endpoint is included.

Known limits

• The triage console is read-only; human collaboration remains planned for
  v0.3.1.
• Routing is a versioned deterministic keyword/risk policy, not a replacement
  for organization-specific incident procedures.
• Model extraction runs synchronously inside the request with a hard two-second
  total budget; it has no worker or background retry.
• Historical records preserve only their original reason because earlier
  versions did not capture facts or retrieval evidence.
• This release does not add order tools, refunds, live agent replies, assignment,
  notes, or resolution actions.

中文摘要

v0.2.9 将原有自由文本转人工记录升级为可追溯的结构化交接包，并新增独立的双语只读
分流页面。账户安全、未授权交易和即时安全风险固定为紧急；知识冲突、私有业务操作和重大
投诉固定为高优先级。可选模型只能在 2 秒总预算内改进摘要、带消息原文引用的事实和缺失
信息，不能修改类别、优先级、风险、队列或下一步。旧记录会幂等回填到人工分流队列，不会
补造历史事实；新记录通过事务保证助手消息、转人工日志、交接包和会话状态要么全部成功，
要么全部回滚。

v0.2.7 — Grounding, Citations & Idempotency

Product impact

v0.2.7 makes the answer boundary explicit and makes write retries safe. The server now decides whether to return a deterministic FAQ, generate from sufficient retrieved evidence, or refuse before answer generation. That decision and its source snapshot survive conversation history, while optional idempotency keys prevent repeated JSON/SSE writes from duplicating side effects.

Highlights

• Explicit direct_faq, grounded_generation, and refusal answer modes.
• Persisted grounding status, reason, and FAQ/document source snapshots.
• Deterministic refusal for missing, weak, conflicting, and recognized high-risk evidence paths.
• Human escalation before generation for unsupported actions and explicit requests.
• SQLite-backed, owner-scoped Idempotency-Key replay for supported JSON/SSE mutations.
• Synchronous frontend submission guards for chat, ratings, configuration, FAQ, review, document, and authentication workflows.
• Abortable provider timeouts, readiness probe, and bounded graceful shutdown.
• Architecture documentation covering topology, trust boundaries, failure behavior, and evidence-based scaling triggers.

Verification

• Core regression and TypeScript checks passed.
• FAQ evaluation: 11 cases; Top1, Top3, and no-match accuracy 100%.
• Document evaluation: 12 real-format cases; Top3 100%, MRR 0.958.
• Mixed knowledge evaluation: 6/6 Top1.
• Playwright: 41 API and Chromium workflows passed locally.
• GitHub Actions run 29882816837 passed regression, retrieval evaluation, E2E, and build steps.
• Production build, diff check, and independent adversarial standards/specification reviews passed.

See the full evidence package and architecture document.

Known limits

• Grounding thresholds are initial deterministic safeguards and still need versioned calibration.
• Source cards are retrieval snapshots, not claim-level entailment verification.
• Conflict detection is limited to duplicate normalized direct-FAQ questions with different answers.
• Idempotency records are deployment-local, retained for 24 hours, and do not coordinate multiple independent API stores or external business systems.
• Multipart uploads use workflow-specific submission and content-duplicate protection rather than generic response replay.
• The default deployment remains one API instance with SQLite and an in-memory vector index.

This project remains pre-1.0. APIs and persisted data may change before a stability review.

v0.2.6 — Document RAG Foundation

Product impact

v0.2.6 turns the FAQ-first MVP into a small but complete document-grounded support workflow. Administrators can upload, inspect, retry, enable, disable, and delete enterprise documents; customer answers can cite the document and chunk used as evidence.

Highlights

• TXT, Markdown, text-layer PDF, and DOCX ingestion.
• Semantic chunking and FAQ/document hybrid retrieval.
• Source-aware recall so one knowledge type does not crowd out the other.
• Compact document, chunk, and page provenance in chat and knowledge-review snapshots.
• Deterministic no-key fallback to the best original source excerpt.
• Environment-only model credentials and atomic non-secret configuration writeback.
• Compatible intent output negotiation across json_schema, json_object, validated text JSON, and keyword fallback.
• Bilingual, light/dark, desktop/mobile admin workflows.

Verification

• FAQ eval: 11 cases; Top1 100%, Top3 100%, no-match 100%.
• Document eval: 12 real-format cases; Top3 100%, semantic-v1 MRR 1.000.
• Playwright: 32 API and Chromium workflows passed.
• Regression, TypeScript, production build, fresh-archive install/build, and diff checks passed.

See the full evidence package.

Demo and build story

• The attached smart-customer-service-v0.2.6-demo.mp4 is a 2m57s Mandarin walkthrough recorded against the real local application.
• The AI-assisted development case study explains what Codex accelerated, which decisions remained human, what failures were caught, and why the project did not add speculative multi-agent or vector-database infrastructure.

Known limits

• Parsing and embedding are synchronous and bounded inside the Express process.
• PDF requires a text layer; OCR and image understanding are not included.
• Formal citations/page jumps, reranking, and no-evidence refusal are planned next.
• SQLite plus the in-memory vector index remains the intended small-deployment path.
• Existing dependency findings through bcrypt/tar, uuid, and xlsx remain documented; xlsx currently has no upstream fix.

This project remains pre-1.0. APIs and persisted data may change before a stability review.