[feat] Deepen a team's knowledge: relations across every asset, delivered to every tool, proved on the task bank

Start with the existing graph schema in src/wiki-engine/core/graph-index.schema.ts, then trace asset loading and delivery through src/manifest-schema.ts, src/recall.ts, and src/tools.ts. The issue names the first slice: derive relations read-only, extend the graph and lint/recall, then measure a deepening commit against the task bank. Done means those relations are visible and the before/after task result is recorded; dependencies #1180, #1402, #1537, and #1221 need to be considered.

Goal

Teamai gives every tool the team's assets: the skills, rules, instruction blocks and agents are written into the places each tool reads them from, and a session can recall the rest. That is presence. It is not association and it is not structure: nothing says that a rule, a doc, a learning and the code page they describe are about the same thing, and nothing restructures them when one of them changes.

The relation model exists — for code only:

• teamwiki/.indices/graph-index.json holds typed edges between code pages: DEPENDS_ON, IMPLEMENTS, MAPS_TO, CONTAINS, REFERENCES, CONFLICTS_WITH, SUPERSEDES (src/wiki-engine/core/graph-index.schema.ts:16). Recall already walks them: a code hit is boosted by its neighbours (RELATION_WEIGHT, src/code-knowledge-recall.ts:52).
• Everything else — learnings, docs, rules, skills — is related by nothing but a namespace, which is a path segment (src/manifest-schema.ts:112), and indexed flat: one TF-IDF index over the texts (src/recall.ts:438).

So a team's knowledge is a pile of files with a code graph beside it. Two things follow, and both are what a member feels as "teamai initialized it and stopped":

• The relations never reach a model. docs, learnings and wiki are never written into a tool's own directory — their pull is a no-op (src/resources/repo-resource.ts:218) — and the graph itself stays in the team clone. A tool gets flat Markdown and has to rediscover the relations by reading.
• The deepening that exists is neither published nor structured. teamai codebase --deep-enrich writes one document per component (src/deep-enrich.ts:421), each page independent of the others, into the clone — and never commits or pushes it, so a team repo never gets it ("Only an import publishes to the team repo", src/import-codebase.ts:606; #1537). The method we already have for the structure — the wiki skill's G1–G9 graph documents, its confidence labels, its consistency check and its end-to-end question set (skill-data/wiki/SKILL.md:190) — is not wired into the CLI at all: its own table says "Compile into the wiki after K3 | Skip" (skill-data/wiki/SKILL.md:308).

This proposes the missing half: one relation graph over the whole team's knowledge, delivered to every tool in a form a model can use, and measured on the task bank, so a deepening change is proved instead of asserted.

Example

A team has a rule, a doc, a learning and the code:

rules/payments.md                    "every payment goes through ledger receipts; no direct writes to ledger"
docs/payments-overview.md            how the payment flow works
learnings/ops/2026-10-12-ledger-timeout.md   "the receipt write times out at 3s; retry once"
teamwiki/evidence/code/pay/…/modules/ledger-receipts.md

Today, a session that asks "why did the payment job fail?" recalls the pages that match the words: the learning and the module. It does not learn that the rule governs the module, that the learning corrects the module's doc, or that the doc is stale since the learning. The agent re-derives the relation by reading three files, or misses one.

With relations, the recall result carries the relation, so the session starts with it:

ledger-receipts (code)  ← IMPLEMENTS — rule:payments
ledger-receipts (code)  ← MAPS_TO — docs/payments-overview
docs/payments-overview  ← SUPERSEDES — learning:2026-10-12-ledger-timeout

The session applies the rule and the correction without working out that three files are about one thing.

And the team that added the relation can say what it bought: the relation is an asset in the graph, and the task bank can tell whether the tasks that touch payments stopped failing.

Scope

1. One relation vocabulary for the whole team

Keep RelationType as it is (src/wiki-engine/core/graph-index.schema.ts:16) and widen the node kinds from code pages to the team's assets: skill, rule, doc, learning, agent, workflow, scorer, code. The edge already carries what an audited edge needs: evidence, weight, source, origin (src/wiki-engine/core/graph-index.schema.ts:95).

A first vocabulary, every relation of it already meaningful for code and reused as it is:

relation	between	example
IMPLEMENTS	code ↔ rule / doc	the ledger module implements the payments rule
REFERENCES	any ↔ any	the rule references the doc
SUPERSEDES	learning ↔ doc / rule	the learning corrects the doc
CONFLICTS_WITH	rule ↔ rule	two rules give opposite answers
MAPS_TO	doc ↔ code	the doc describes the module
CONTAINS	namespace ↔ asset	the directory structure itself

No new relation type is needed for the first slice.

2. Where the edges come from — deterministic first

Three sources that need no model and can be audited:

• Explicit. A see also: / applies to: line in a skill's or rule's frontmatter. Human-written, team-reviewed, reviewed like any other change.
• Derived from the records the team already keeps. A label records the team skills a session loaded (used.skills, src/scorers/label.ts:77) and the sessions that hit a friction reminder. A skill loaded in exactly the sessions where a rule's rule fired is an edge with evidence behind it.
• Derived from the existing code graph. The reconciler already maps a product page onto a code page by term overlap, with a confidence (MAPS_TO, src/wiki-engine/knowledge-reconciler.ts:324). The same pass maps a rule or a doc onto a code page, under the same honesty rule the wiki skill states: "every relation in the graph must have an explicit basis in a component document; never guess from names" (skill-data/wiki/SKILL.md:293).

A model-assisted pass stays optional and off by default, as the skill is today: it proposes edges with a confidence, and a human accepts them into a review branch, the way teamai recall promote does for a promoted learning (docs/guide/knowledge.md:127).

3. The relations reach every tool

This is the part that makes it deepening rather than more files in the clone:

• Deliver the map, not the map's contents. A tool gets a compact knowledge map — the pages and the edges between them — in the place that tool reads, declared once in the descriptor (src/tools.ts), so every tool's shape is written down once (#1221). The map is bounded (the top edges per node, the relations of the assets a session actually touches), so it does not grow with the team's knowledge.
• Relations ride with the asset. A delivered skill or rule carries its edges as a short "related" block, so the model sees the relation next to the thing it must act on, not in a second file it has to find.
• Recall answers with relations. A hit carries its neighbours and the relation that links them, so the agent gets the association and not only the text.
• Nothing is delivered that the team did not write. The map is derived from the team's assets and the graph in the team clone: no new content, no second copy of the corpus.

4. The knowledge is restructured, not only deepened

• The deepening that exists has to reach the team repo: codebase --deep-enrich and --reconcile commit and push the way import does (#1537). Until then the richest knowledge teamai builds never leaves the clone.
• The structure the wiki skill describes (the G1–G9 graph documents, the router, the confidence labels) becomes the CLI's own, so the pages of one component reference the pages of the others instead of standing alone (src/deep-enrich.ts:421).
• The lint that exists becomes a gate over the whole knowledge, not only over the code: codebase --lint already measures nodeCount, edgeCount, orphanNodes and connectivity (src/codebase-wiki-lint.ts:166). An asset nobody relates to is an orphan, and the team sees it.

5. The deepening is proved on the task bank

This is what makes the proposal worth doing, and it is what the task bank buys:

• #1402 turns a session into a task; #1180 runs a suite as a workflow. The run record already has a benchmark slot, reserved and never written (src/dashboard/scorers.ts:60), and the dashboard already leaves benchmark labels out of the session page.
• The cohort machinery already splits labels at a team commit: before / after / notRecorded (src/scorers/results.ts:94). A deepening commit is such a commit.
• So the measurement is: the tasks that pass after the deepening commit and failed before it — the same tasks, the same judge, the same rubric, one team revision apart. That is the number #407 asks for ("某个团队 Skill、Rule 或知识上线后，是否真的改善了 AI 执行效果？"), and the number teamai recall promote guesses today with its confidence formula.
• Without relations, the task bank can only measure with a team against without a team — presence. With relations it can measure deep against shallow, which is the claim this proposal makes.

First slice

Small enough to land on its own, and each part of it visible:

1. A read-only pass that reads the team's assets and prints the relations it can derive deterministically — explicit frontmatter, the reconciler's term overlap, the delivery records — before anything is written.
2. The edges land in the same graph the code pages use; codebase --lint counts orphans over the assets too, and teamai recall shows a hit's neighbours with the relation that links them.
3. One team's deepening commit, measured on the task bank: the tasks that pass after it that failed before.

Not in this proposal

• Not a new storage format: the graph the code pages use is the graph the assets use.
• Not per-tool knowledge formats written by hand: the descriptor decides where each tool's map goes (#1221).
• Not a model that rewrites a team's knowledge unattended: edges are proposed, the team accepts them.
• Not a new scoring method: the task bank and the judge already exist; this only records which run was a benchmark.

Dependencies

• #1180 (benchmark suites as workflows) and #1402 (session-to-task) for the measurement half.
• #1537 (--deep-enrich publishes) for the restructuring half.
• #1221 (one descriptor per tool) for the delivery half.
• #408 and #1469 for the assets-health and skill-routing view of the same assets.

Open questions

• Is the map delivered as a file per tool, or as an index the tool reads on demand? The first is simple; the second costs a lookup per session.
• Does a relation between two assets count as knowledge the team owns — reviewable in a PR — or as a derived fact that can only be rebuilt?
• Which assets are worth relating first: rules to code, or learnings to docs? Learnings are what a team writes daily; rules are what it forgets.