docs(extension): 修正 Hub/Spoke ownership 边界

00-meta/skills/edit-svc-shared-docs/SKILL.md

@@ -39,6 +39,10 @@ Apply this before editing any doc that may be mixed.
 2. Reject shared promotion if the statement depends on one Spoke's local class names, method names, table names, or runtime sequencing unless those names are themselves the durable contract.
 3. Reject shared promotion if the remaining local details would lose a readable home.
 4. Prefer Spoke-local `AGENTS.md` and `docs/30-unit-tdd/` for implementation vocabulary, runtime hazards, and local mechanics.
+5. Check delivery owner, durable owner, interface layer, and external capability owner independently. First-party distribution,
+   current delivery pressure, importance, or successful acceptance on one axis does not prove promotion on another.
+6. Concrete Extension behavior stays with the owning Extension unless it proves a product-wide claim or cross-unit contract
+   that remains meaningful without naming that implementation.
 
 ## Workflow B: Update Hub Shared Docs
 

10-prd/behavior/capabilities.md

@@ -45,16 +45,6 @@
 - related claim(s): accept memo-like capture through familiar clients
 - non-goal: a memo-compatible backend does not become a complete clone of the external product and does not include browsing or using the wider InKCre info-base
 
-## Capability: Syndicated feed collection
-
-- related claim(s): collect external information into reusable units; reliably collect RSS and Atom feeds
-- non-goal: RSS/Atom collection does not include a feed-reader UI or make fetched full text and downloaded enclosures part of feed-authored authority
-
-## Capability: Email communication collection
-
-- related claim(s): collect external information into reusable units; preserve email communication records for later use
-- non-goal: email collection does not imply a mailbox mirror, a dedicated inbox UI, automatic attachment download, or the complete send/reply/agent action surface
-
 ## Capability: Multi-runtime peer participation
 
 - related claim(s): organize information in one reusable info-base

10-prd/behavior/claims.md

@@ -18,24 +18,6 @@
 - realization pointers: `../../20-product-tdd/system-state-and-authority.md`, `../../20-product-tdd/cross-unit-contracts.md`
 - impact on existing claims: organization optimizes reusable product memory; it does not own collection-time graph construction or retrieval indexes.
 
-## Claim: InKCre reliably collects RSS and Atom feeds
-
-- claim intent: a configured syndication source should preserve feed-authored information as reusable graph state while avoiding avoidable duplicate updates.
-- evaluation dimensions: RSS 2.0 and Atom sources use exact native identity when available, scope incremental state to its authority, keep full text separate from feed-authored content, and expose enclosure materialization as an explicit policy or command.
-- evidence expectation: real RSS and Atom documents prove create, replay, update, conditional request, unidentified-item policy, partial failure, full-text enrichment, and semantic enclosure behavior through the ordinary collection Job path.
-- source rationale: `../_drivers/market-and-user-pressures.md`, `../_drivers/operational-realities.md`
-- realization pointers: `../../20-product-tdd/knowledge-capability-contract.md`, `../../20-product-tdd/claim-realization-matrix.md`
-- impact on existing claims: feed collection realizes the general collection claim; it does not add a feed-reader UI, make enrichment primary authority, or require fuzzy content identity.
-
-## Claim: InKCre preserves email communication records for later use
-
-- claim intent: a person should be able to collect current and historical email communication at low cost without turning the info-base into an email-server mirror.
-- evaluation dimensions: ordinary and backfill collection preserve useful message structure, participants, mailbox membership, flags, MIME metadata, and reply/reference evidence; remote bytes remain materializable on demand; source-owned remote actions are explicit and configurable.
-- evidence expectation: a real IMAP server plus generic Job/Cron execution evidence prove ordinary and scheduled collection, bounded historical backfill, exact remote MIME materialization, and generic info-base viewing through the same persisted Mail graph.
-- source rationale: `../_drivers/market-and-user-pressures.md`, `../_drivers/operational-realities.md`
-- realization pointers: `../../20-product-tdd/knowledge-capability-contract.md`, `../../20-product-tdd/claim-realization-matrix.md`
-- impact on existing claims: Mail realizes collection and use through one graph; it does not add a Mail-only inbox product, guarantee mailbox mirroring, or complete the future email client/agent vision.
-
 ## Claim: InKCre exposes info-base information for retrieval and downstream use
 
 - claim intent: people and downstream capabilities should be able to find and navigate useful information in the info-base.
@@ -49,7 +31,7 @@
 
 - claim intent: a person, Agent, or downstream capability should be able to find existing information whose meaning is related to a natural-language query without first generating an answer.
 - evaluation dimensions: one bounded query returns globally ranked blocks and relations with score metadata; relation direction contributes to meaning; unavailable or stale derived support is excluded rather than repaired during the read.
-- evidence expectation: a real provider embeds graph state collected through ordinary Memos, RSS, Atom, storage, resolver, and organization boundaries; judged primary entities enter the global top three and outrank explicit distractors.
+- evidence expectation: a real provider embeds graph state from ordinary collection, storage, resolver, and organization boundaries; judged primary entities enter the global top three and outrank explicit distractors.
 - source rationale: `../_drivers/market-and-user-pressures.md`, `../_drivers/business-and-service-objectives.md`
 - realization pointers: `../../20-product-tdd/semantic-retrieval-and-peer-capabilities.md`, `../../20-product-tdd/claim-realization-matrix.md`
 - impact on existing claims: this realizes semantic retrieval only; feature retrieval, graph-navigation retrieval, answer generation, and Chat InKCre remain independent product capabilities even when another capability is also implemented.

10-prd/behavior/rules-and-invariants.md

@@ -52,19 +52,19 @@
 
 - rationale: stable native identity can justify reconciliation, while content fingerprints and time cutoffs provide weaker and less stable guarantees.
 - violation impact: uncertain external information may overwrite the wrong graph state or a heuristic may be misrepresented as identity.
-- linked claim(s): collect external information into reusable units; reliably collect RSS and Atom feeds
+- linked claim(s): collect external information into reusable units
 
 ## Collection preserves source meaning without becoming a remote mirror
 
 - rationale: a source may synchronize facts and explicit remote actions while the info-base remains reusable graph memory rather than a replica of the source system.
 - violation impact: deletion, folder, flag, or byte-fetch behavior would either erase useful information without product intent or force every source into an expensive mirroring contract.
-- linked claim(s): collect external information into reusable units; preserve email communication records for later use
+- linked claim(s): collect external information into reusable units
 
 ## Source-authored facts and semantic enrichment remain separate
 
-- rationale: fetched full text and downloaded enclosure bytes can improve use without becoming authority for what a feed authored.
+- rationale: derived or externally fetched content can improve use without becoming authority for what a source authored.
 - violation impact: enrichment failure would corrupt primary collection semantics and provenance would be lost.
-- linked claim(s): reliably collect RSS and Atom feeds; expose info-base information for retrieval and downstream use
+- linked claim(s): collect external information into reusable units; expose info-base information for retrieval and downstream use
 
 ## One deployment is one owner context
 

10-prd/behavior/scope.md

@@ -4,8 +4,6 @@
 
 - automatic or event-driven collection of information from external systems
 - low-friction memo-like capture through bounded compatible backends or collectors
-- RSS 2.0 and Atom collection with source-scoped incremental state, default full-text enrichment, and policy-controlled enclosure materialization
-- IMAP email collection with ordinary incremental runs, bounded historical backfill, source-owned remote-state policy, on-demand MIME materialization, and generic info-base rendering
 - organization of information already in the info-base when it improves later use
 - feature, semantic, and graph-navigation retrieval, with indexing and embedding as application support
 - extension-based capability addition for source, resolver, storage, sink, or bounded protocol behavior
@@ -18,8 +16,6 @@
 - wire transport internals and local interface details
 - Spoke-local runtime operations and deployment procedures
 - multi-tenant or per-user ownership and access control inside one InKCre deployment
-- feed-reader UI, OPML management, or exhaustive compatibility with every malformed syndication document
-- a Mail-only inbox/folder/message-list product or complete compose/send/reply email-agent behavior in the current Mail slice
 
 ## Open Question
 

10-prd/behavior/workflows.md

@@ -16,22 +16,6 @@
 - exception flow: the operation exposes its own correctness and partial-effect boundary rather than being treated as a hidden part of collection
 - observable outcome: a testable graph or use-facing improvement exists on information that was already persisted
 
-## Workflow: RSS And Atom Collection
-
-- actor: a configured RSS 2.0 or Atom source and an eligible Job runner
-- trigger: a manual collection command or configured schedule creates a pending job
-- normal flow: the source conditionally fetches a bounded feed document, reconciles the feed and identifiable items by exact native evidence, persists enclosure metadata, then attempts configured full-text and enclosure enrichment without replacing feed-authored authority
-- exception flow: unidentified items follow explicit create/discard policy; primary item failures and enrichment failures remain visible in job diagnostics, and source state advances only after a successful contentful snapshot
-- observable outcome: resolver-readable feed/item/enclosure graph state exists, exact replays are idempotent, and optional semantic children remain distinguishable from primary source facts
-
-## Workflow: Email Communication Collection
-
-- actor: a configured Mail source and any eligible Job-capable peer
-- trigger: a person requests ordinary collection or bounded backfill, or a configured Cron creates an ordinary collection Job
-- normal flow: the source reads protocol facts, reconciles exact occurrences and best-effort canonical messages, persists source/mailbox/message/participant/body/MIME/flag/reply graph facts, and advances only source-owned incremental checkpoints whose accepted effects are durable
-- exception flow: one Job is one attempt and never retries itself; mailbox-local failure may leave accepted partial graph effects; missed Cron occurrences are not replayed; attachment bytes remain remote until explicitly materialized through their resolver
-- observable outcome: collected communication can be discovered and rendered through generic info-base navigation, while later collection updates observed mailbox membership and flags without treating the info-base as a remote mirror
-
 ## Workflow: Retrieval And Use
 
 - actor: application capability, sink, or downstream workflow

20-product-tdd/claim-realization-matrix.md

@@ -11,11 +11,7 @@ Map product claims to participating units and clarify each unit's technical resp
 
 | Product claim | Reference realization | Participating units | Evidence boundary |
 | --- | --- | --- | --- |
-| Collect external information into reusable units | Memos-compatible backend maps native requests to memo-family blocks, relations, resolver output, and storage-backed attachments | `core-py`; released MoeMemos client as acceptance actor | Bounded Memos 0.29.1-compatible API and MoeMemos Android 2.0.4 journey; not full Memos server or collector coverage |
-| Reliably collect RSS and Atom feeds | RSS extension maps bounded RSS 2.0/Atom snapshots to feed, item, enclosure, full-text, and semantic-content graph state | `core-py` | Real-protocol HTTP doubles, PostgreSQL graph acceptance, optional live endpoint smoke, exact replay/update/state/enrichment cases; not a feed-reader product |
-| Preserve email communication records for later use | Mail extension maps protocol-neutral Mail facts to source, mailbox, canonical email, participant, body, MIME, flag, and reply/reference graph state; remote MIME bytes are materialized lazily | `core-py`; `client-web` as Job peer, info-base navigation host, and resolver consumer | Real Dovecot/IMAP plus PostgreSQL proves ordinary collection, bounded backfill, remote materialization, and built-browser rendering; not a Mail-only inbox or complete email agent |
-| Accept memo-like capture through familiar clients | Memos extension provides the first memo-family backend access mode | `core-py`; `client-web` for deployment-scoped extension configuration | Backend write/read, comments, attachments, hot credential replacement, hot enable/disable, and graph round-trip |
 | Organize information in one reusable info-base | Explicit focal-block rumination and system-driven media interpretation are admitted organization approaches; Agents may add ordinary graph interpretations while preserving existing graph authority | `core-py`; `client-web` as an explicit rumination trigger and retrieval consumer | Real-provider Resolver/Agent/Tool/graph journeys, meaningful no-write boundary, and bounded independent media candidates; not a complete organization taxonomy, replacement, merge, or linking realization |
 | Expose information for retrieval and downstream use | Semantic retrieval ranks existing Blocks/Relations by meaning; lexical feature retrieval recalls existing Blocks from explainable textual clues; graph-navigation returns endpoint-closed neighborhoods and bounded shortest paths; hybrid composition remains independent | `core-py`; `client-web` and future Agent/application consumers | Pinned real multi-source/document/media topology corpus, real embedding and multimodal providers, local/delegated Peer journeys, and browser List/Graph navigation; not answer generation or Chat InKCre |
 | Retrieve semantically related info-base entities | Resolver/Relation projections feed profile-scoped derived embeddings; one domain facade executes locally or delegates the exact capability to an eligible Peer | `core-py`; `client-web` Peer consumer | Freshness/invalidation/maintenance checks, global Block/Relation ranking, real provider quality gate, exact-target and failover/outcome-unknown protocol cases |
-| Recall blocks from lexical feature evidence | Block-local Resolver labels/text feed one derived record per Block; one facade ranks exact/substring/term evidence locally or through an eligible Peer | `core-py`; `client-web` Peer consumer and InfoBaseListView host | Exact identifiers, Chinese fragments, Mail metadata, PDF body, real image/audio/video faithful text, Agent interpretation, freshness/Jobs, delegated Peer, and built-browser navigation |
+| Recall blocks from lexical feature evidence | Block-local Resolver labels/text feed one derived record per Block; one facade ranks exact/substring/term evidence locally or through an eligible Peer | `core-py`; `client-web` Peer consumer and InfoBaseListView host | Exact identifiers, Chinese fragments, source metadata, document bodies, real image/audio/video faithful text, Agent interpretation, freshness/Jobs, delegated Peer, and built-browser navigation |

20-product-tdd/cross-unit-contracts.md

@@ -27,15 +27,15 @@ Record durable data and behavior contracts that span more than one unit reposito
 
 ## Info-Base Ownership Contract
 
-- Collection, organization, application, graph authority, resolver/storage composition,
-  extension protocol authentication, and the Memos reference integration are owned by the
+- Collection, organization, application, graph authority, resolver/storage composition, and
+  extension protocol authentication are owned by the
   [Knowledge Capability Contract](knowledge-capability-contract.md).
 - Sources and extensions may propose graph data, but info-base owns persisted graph insertion.
 - Embedding generation may be triggered during ingestion, but embeddings remain derived
   application support rather than source-owned or info-base-owned authority.
-- Generic one-shot Jobs and Crons, Source graph anchors and writable-Storage selection, the
-  Mail reference graph/materialization integration, and info-base navigation/solved-content
-  boundaries are owned by the same Knowledge Capability Contract.
+- Generic one-shot Jobs and Crons, Source graph anchors, writable-Storage selection,
+  source graph/materialization patterns, and info-base navigation/solved-content boundaries
+  are owned by the same Knowledge Capability Contract.
 
 ## Semantic Retrieval And Peer Capability Contract