Why: two field reports against the live build — deliverable cards never
appeared in chat (only model-written filenames) and the artifacts panel
felt dead. Root cause found in runmgr.ExecuteTool: registry tools that
write artifacts via rc.WriteArtifact never had res.Artifact set (only
the oversized-result path did), so llm.go never emitted artifact_ref
parts for real tool output; the unit suite passed via fakes that set
it directly. Architecturally, document generation moves back to the
agent (user directive): system provides execution primitives and the
delivery bridge, not domain tools like write_docx.
Evidence:
- runmgr: toolCtx tracks artifacts written during a call and
ExecuteTool backfills res.Artifact (new runmgr test proves
write_artifact now surfaces one; negative test: no phantom artifact)
- new tools/register_artifact: bridge from workspace files (binary
docx/xlsx/pptx/pdf/images, <=10MB) to deliverable artifacts;
run_shell/run_python interpreter executors are designed
(script-to-disk + whitelisted bash/python3, sandbox cwd, caps) and
land in a follow-up batch behind the security gate decision
- removed builtin write_docx + its prompt; write_artifact prompt now
text-only with explicit no-binary guidance; new always-on base
prompt base.deliverables teaches the generate->register->summarize
workflow with python-docx/openpyxl/python-pptx recipes;
task.doc-minutes rewritten to the workflow
- final-output contract: inline <think> blocks in streamed content are
split into thinking (process) parts so the final reply stays clean
(unit + runner tests)
- go test ./... 19 packages ok; vet clean
Impact: every tool artifact now lands as an in-chat deliverable card;
mock #doc unchanged as demo fixture; binary office mimes stay out of
the text index; write_docx callers see the tool gone (prompt reroutes
them).
Refs: task feature/agent-native-deliverables-r1
Why: docx deliverables were plain text saved with a .docx name (no
headings/tables/styles), and the artifact_ref part was marked Process
so the deliverable vanished into the collapsed process section — the
user saw only model-written text like "📄 xxx.docx 工件 ID …" instead
of an openable, formatted document delivered in the conversation.
Evidence:
- new internal/docgen: Markdown -> styled OOXML (Title/Heading1-4,
numbered+bullet lists with numbering.xml, GFM tables with shaded
header, quotes, code blocks, bold/italic/strike, real hyperlinks);
zero third-party deps; tests cover zip structure, XML well-formedness,
numbering refs, hyperlink rels, escaping, plain-text fallback
- ingest round-trip test proves generated docx parses back to blocks
- new write_docx builtin tool (markdown in -> styled .docx artifact);
write_artifact prompt now routes Word docs to it; task.doc-minutes
output contract requires write_docx delivery
- llm.go: artifact refs collected as deliverables and appended as
content parts AFTER the final text (pinned tail, not process); mock
#dogfood path generates a real styled docx; runmgr skips string
indexing for binary office mimes
- go test ./... 19 packages ok (incl. new e2e asserting <w:tbl> and
title text inside the artifact served by the API)
Impact: model-written documents open in Word/WPS with real layout and
preview with formatting (mammoth maps Heading1-4 to h1-h4); every tool
artifact now lands as a visible in-chat card; no behavior change for
text artifacts.
Refs: task feature/deliverable-docx-r1
Why: D46/D47 approved — artifact_ref parts left only a name line in model
context (next-turn amnesia on big tool results), and artifacts had no
inbox presence unlike submit_card products.
Evidence: ctxasm ArtifactResolver backfills UTF-8 artifact text with the
card char limit (Truncations + artifact(n) observable; binary keeps
placeholder); runmgr runCtx.Artifact; llm.go auto-creates a result facade
card (summary kv + doc-ref) when a tool result is truncated, suppressed
when the run already submitted an explicit card; mock #doc demos the
facade; new tests TestAssembleInputArtifactBackfill,
TestLLMRunnerArtifactFacadeCard/Suppressed, e2e TestArtifactFacadeCard.
Impact: frontend unchanged — artifact chips and doc-ref already resolve
via docBridge; no wire protocol change.
Refs: documents proposal 2026-09-30-card-stream-artifact-unify-project-inbox.md (D46/D47).
Why: D44/D45 approved — card content streaming lets users watch long
artifacts materialize in the inbox instead of a single submit_card blob.
Evidence: cardsvc Append with 250ms emit throttle (persist-every-append);
runmgr Begin/Append/CommitStreamCard + finishRun fallback marking
uncommitted stream cards done/failed with warn tone; llm.go declares the
three tools under ui.cardflow with hallucination rejection; mock
#cardstream demo; new unit tests (TestLLMRunnerCardStreamTools/Gated,
TestAppendStreamThrottleAndMerge) and e2e TestMockCardflowStreamLoop.
Impact: no change to existing submit_card path or wire protocol;
card.updated payload already carried full cards (projection semantics).
Refs: documents proposal 2026-09-30-card-stream-artifact-unify-project-inbox.md (D44/D45).
Why: T2 of the interaction foundation — activity cards as first-class state
objects behind the right-rail inbox (proposal D25): upload ingest cards
(SR-A5 failures explicit, artifact retrievable), HITL projection cards
(double-presence, ref-linked two-way sync), squad orchestration cards and
the mock #upload demo of the full card lifecycle.
Evidence: go test ./... green across 14 packages incl. new cardsvc suite
(lifecycle, action labels and idempotency, pin/dismiss, owner isolation,
resolve-by-ref idempotency) and updated migration test (v6 activity_cards,
both dialects); events flow through the session event buffer (persist, seq,
replay); receipts appended to the conversation timeline on card actions.
Impact: additive; cards disabled (SetCards nil) degenerates to the T0
baseline; upload cards persist at project level per the v1 inbox boundary
(conversation-scoped inbox; project-level aggregation is follow-up).
Refs: modules/documents docs/proposals/2026-09-30-ui-inbox-command-workspace.md
weichen
weichen