docs(security): centralize shared boundary model (#19)

- define project-wide actors, assets, trust boundaries, and proportional classification
- keep executable admission and runtime mechanics with each Spoke
- establish an independent ownership-correction task packet

Author: xiaoland

20-product-tdd/security-boundary-model.md

@@ -0,0 +1,169 @@
+# Security Boundary Model
+
+## Purpose
+
+This document defines the shared security reasoning model for InKCre。It helps Humans and
+implementations distinguish a vulnerability from an ordinary bug，hardening opportunity，
+operational risk or accepted risk without maximizing controls for their own sake。
+
+A security requirement needs an identified actor，protected asset，intended boundary，credible
+attack path and proportionate control。Exact protocol admission，database grants，rendering，
+credential handling and deployment behavior remain owned by the Unit that implements them。
+External vulnerability reporting remains owned by the applicable repository `SECURITY.md` and
+organization policy。
+
+## Shared Deployment Model
+
+```mermaid
+flowchart LR
+  owner["Deployment owner"] -->|"operates and configures"| deployment["InKCre deployment"]
+  peer["Admitted Peer"] -->|"admitted protocol"| deployment
+  caller["Untrusted caller"] -->|"public or protocol surface"| deployment
+  source["External source and untrusted content"] -->|"collection"| deployment
+  extension["Reviewed Extension artifact"] -->|"declared runtime capability"| deployment
+  deployment -->|"selected requests and data"| provider["External provider"]
+  deployment -->|"persists"| infobase["Info-base"]
+```
+
+The arrows are trust and authority boundaries，not a promise that every deployment exposes every
+path。Host isolation，transport termination，backups and provider custody are supplied by the
+selected deployment and must be assessed with its Unit-owned runtime documentation。
+
+## Actors And Authority
+
+| Actor | Shared posture |
+| --- | --- |
+| Deployment owner | Trusted administrator of one deployment。Can configure its Peers，inspect deployment-owned persistence and replace deployed artifacts。 |
+| Admitted Peer | Inside the deployment trust domain after satisfying one executable Peer protocol。Peer equality does not imply identical execution capability，but the current product does not promise per-user or per-tenant isolation between admitted Peers。 |
+| Untrusted caller | Has no deployment authority until admitted by the relevant public，Peer or Extension protocol。A public observation grants only its documented result。 |
+| Extension protocol caller | Untrusted until the Extension-owned admission mechanism succeeds。Successful Extension admission grants only that protocol's intended authority。 |
+| External source and collected content | Untrusted data。Collection does not make malformed，adversarial，stale or misleading content executable or trustworthy。 |
+| Reviewed Extension artifact | Trusted application code within the runtime that admits it。An Extension registry is an organization mechanism，not a sandbox or tenant boundary。 |
+| External provider | Outside the deployment boundary。It receives requests and data deliberately sent by configured capability code，subject to its own policy and credentials。 |
+
+## Protected Assets
+
+- confidentiality and integrity of info-base Blocks，Relations，stored bytes and derived output；
+- credentials and signing material used to admit Peers，Extension callers，Sources，Storages and
+  external providers；
+- the deployment owner's control over collection，organization，retrieval，configuration and
+  deletion；
+- artifact，migration and dependency integrity；
+- availability where an otherwise untrusted actor can cause meaningful denial，resource exhaustion
+  or external cost。
+
+## Shared Boundaries And Invariants
+
+### Admission
+
+Core，database，Peer and Extension protocols may expose different admission surfaces。Authority
+granted by one surface does not silently grant another surface's authority。Public routes reveal
+only their intentionally public observations。
+
+CORS，obscurity，route naming and possession of a non-secret client identifier are not authorization
+boundaries。Exact claims，roles，credentials and denial behavior belong to the implementing Unit's
+executable contract。
+
+### Persistence And Credentials
+
+Persistence operated by the deployment is inside the deployment trust boundary unless a more
+specific topology says otherwise。Persisting a credential in access-controlled deployment
+configuration is not by itself a boundary violation。The relevant questions are whether an
+unauthorized actor can obtain or exercise it through responses，logs，public artifacts，backups or
+unrelated protocols，and whether its replacement and lifetime match the product need。
+
+Encryption at rest，an external secret manager or non-persistence may become justified when a
+deployment introduces an untrusted persistence operator，independently exposed backups，multiple
+users，delegated administration，regulatory duties or another concrete boundary。They are not
+automatic requirements without that boundary。
+
+### Data And Code
+
+Collected content，filenames，metadata，provider responses，resolver input and AI input are data
+controlled partly or wholly by external parties。They must not become code，filesystem paths，SQL，
+templates，privileged commands or authorization decisions without an explicit validating boundary。
+
+Storing or interpreting adversarial content is not itself a vulnerability。Executing it，letting it
+escape its intended data context or allowing it to drive privileged behavior may be one。Each
+presentation Unit remains responsible for safe rendering and interaction at its own boundary。
+
+### Extensions And Artifacts
+
+A reviewed Extension shares the authority of the runtime or Peer that loads it unless that runtime
+explicitly supplies a stronger isolation boundary。Runtime installation of unreviewed code is not
+part of the current shared product contract。Artifact construction，dependency admission and release
+integrity remain owned and enforced by the delivering repository。
+
+### Privileged Operators
+
+The deployment owner，host administrator，migration authority and anyone able to replace a running
+artifact already hold high authority within their scope。Protecting a deployment from its own fully
+privileged operator is not a default product goal；a deployment that separates these roles must
+document the new boundary explicitly。
+
+## Security Classification
+
+A vulnerability requires both security harm and a credible attack path。Examples include an actor
+crossing an intended boundary to：
+
+- read，create，change or delete protected data without the authority granted by the relevant
+  protocol；
+- forge or bypass admission and gain materially greater authority；
+- cause attacker-controlled data to execute code or privileged commands；
+- expose credentials or private content through responses，logs，artifacts，caches，backups or
+  providers；
+- compromise artifact，migration or dependency integrity in a way that reaches users；
+- cause material denial of service or external cost from an otherwise untrusted position。
+
+A surprising behavior，best-practice deviation，missing defense-in-depth layer or hypothetical
+consequence without a boundary crossing is insufficient by itself。It may still be an ordinary bug，
+privacy issue，hardening opportunity，operational risk or accepted risk。
+
+## Common Non-Boundaries
+
+Unless another topology introduces a different actor or authority boundary，the following are not
+vulnerabilities by themselves：
+
+- a deployment owner reading or changing its own configuration，persistence，backups or process
+  memory；
+- one admitted Peer exercising a capability intentionally shared with admitted Peers；
+- reviewed Extension code reaching resources intentionally available to its runtime；
+- a credential being persisted within access-controlled deployment configuration；
+- absence of encryption at rest or an extra authentication layer without a demonstrated
+  unauthorized reader or caller；
+- malformed or hostile collected content being stored as inert data；
+- an architectural hardening proposal without an exploit path or user harm；
+- behavior requiring prior host-administrator，migration-authority or artifact-replacement access。
+
+Accurate classification does not prohibit improvement。It prevents reliability，privacy or
+hardening work from borrowing false urgency from the word “vulnerability”。
+
+## Proportionality Method
+
+Before requiring a control or classifying a report，establish：
+
+1. **Actor and capability**：who acts，and what authority do they already possess？
+2. **Asset and harm**：what protected interest changes，leaks，executes or becomes unavailable？
+3. **Boundary**：what intended separation is crossed？
+4. **Attack path**：what reproducible or technically credible steps connect actor to harm？
+5. **Existing controls**：which executable，deployment or operational mechanisms already reduce
+   the risk？
+6. **Control cost**：what dependency，obscurity，failure mode，user friction or operational burden
+   would the proposed control introduce？
+7. **Classification**：vulnerability，ordinary bug，hardening，operational risk or accepted risk？
+
+Prefer the least complex control that materially changes the identified risk。Re-evaluate when an
+actor，asset，deployment assumption or trust boundary changes；do not preserve a conditional answer
+as a timeless rule。
+
+## Ownership
+
+- Shared actors，assets，boundaries and classification method：this document。
+- Product authority and cross-Unit topology：[System State And Authority](system-state-and-authority.md)
+  and [Unit Topology](unit-topology.md)。
+- Exact admission，persistence，rendering，runtime and deployment mechanics：the implementing Unit's
+  executable contract and local durable documentation。
+- External vulnerability reporting：the applicable repository `SECURITY.md` and organization policy。
+
+Update this model when a shared actor，asset，deployment assumption or trust boundary changes。Do
+not duplicate Unit-local mechanics here merely because they are security-relevant。

20-product-tdd/unit-topology.md

@@ -22,6 +22,9 @@ Define cross-unit technical boundaries and ownership so changes do not leak resp
 - Peer equality does not imply identical execution ability. A business facade may execute
   locally on a capable Peer or delegate one exact synchronous capability to another live
   Peer without turning the deployment into a fixed frontend/backend hierarchy.
+- Shared actors，assets，trust boundaries and proportional security classification use the
+  [Security Boundary Model](security-boundary-model.md)。Each Unit still owns its executable
+  admission，rendering，runtime and deployment mechanics。
 
 ## Knowledge Capability Topology
 

docs/index.md

@@ -4,6 +4,7 @@
 
 - [Product requirements](../10-prd/index.md)
 - [Unit topology](../20-product-tdd/unit-topology.md)
+- [Security boundary model](../20-product-tdd/security-boundary-model.md)
 - [System state and authority](../20-product-tdd/system-state-and-authority.md)
 - [Cross-unit contracts](../20-product-tdd/cross-unit-contracts.md)
 - [Knowledge capability contract](../20-product-tdd/knowledge-capability-contract.md)

tasks/shared-security-model-ownership/packet.md

@@ -0,0 +1,35 @@
+# Shared security model ownership
+
+- **Objective**: move InKCre-wide actors，assets，trust boundaries and proportional security-classification method from
+  `core-py` into the shared Hub，then leave core-py with only its runtime-specific application of that model。
+- **Guardrails**: this is an independent ownership correction，not a `knowledge-lifecycle-capabilities` Unit，security audit，
+  control expansion or behavior change。Hub truth must remain meaningful without FastAPI，PostgREST，Alembic，one concrete
+  Extension or one repository's CI。External reporting remains owned by each repository's `SECURITY.md` and organization
+  policy；Spokes retain executable admission，rendering，runtime and deployment mechanics。
+- **Verification**: every migrated claim has one durable owner；Hub navigation reaches the shared model；core-py no longer
+  presents the shared model as repository-local truth；Hub is committed and pushed before the Spoke shared ref moves；Hub and
+  Spoke diffs pass their declared static checks。
+- **Current Truth**: `core-py/docs/30-unit-tdd/security-model.md` mixes stable project-wide reasoning with core-py actors，
+  runtime vocabulary，deployment links and a Memos PAT worked example。Its project-wide content is already consumed as a
+  collaboration boundary across InKCre，so repository-local ownership is misleading。
+- **Next Step**: publish a Hub-owned `20-product-tdd/security-boundary-model.md` containing only shared truth。After Human
+  review and Hub push，bump core-py's `docs/_shared` ref and replace the local monolith with a thin core runtime boundary note。
+
+## Ownership split
+
+### Hub-owned
+
+- deployment owner，admitted Peer，untrusted caller/content，Extension protocol caller，Extension artifact and external
+  provider as shared actor categories；
+- protected info-base，credentials，owner authority，artifact integrity and attacker-reachable availability/cost；
+- admission，persistence，data/code，Extension and privileged-operator trust boundaries；
+- vulnerability versus bug，hardening，operational risk and accepted-risk classification；
+- actor → asset/harm → boundary → attack-path → existing-controls → control-cost reasoning；
+- the rule that deployment topology changes may change a security conclusion without changing the method。
+
+### Spoke-owned
+
+- exact routes，claims，roles，database grants，processes，migrations，logs，probes and deployment sequencing；
+- renderer，native-client and transport-specific data handling；
+- concrete Extension credentials and protocol admission；
+- repository CI/dependency admission and local worked examples。