@kungfu-tech/kfd 1.0.0-alpha.2 → 1.0.0-alpha.20

package/site/kfd-site.json

@@ -10,6 +10,7 @@
   "routes": {
     "home": "/",
     "decisionPattern": "/{number}",
+    "decisionUsagePattern": "/{number}/usage",
     "llms": "/llms.txt",
     "manifest": "/manifest.json"
   },
@@ -23,7 +24,7 @@
       "commitments": [
         {
           "id": "KFD-1",
-          "text": "contracts must not drift."
+          "text": "facts must not drift."
         },
         {
           "id": "KFD-2",
@@ -31,10 +32,10 @@
         },
         {
           "id": "KFD-3",
-          "text": "cooperation must start from transparent value, not coercion."
+          "text": "cooperation must start from trusted value."
         }
       ],
-      "summary": "Together they define the load-bearing path for Kungfu products: make contract worlds explicit, make important claims inspectable, and let humans and agents cooperate through visible value rather than hidden pressure."
+      "summary": "Together they define the load-bearing path for Kungfu products: make facts non-drifting, make trust inspectable from those facts, and let humans and agents cooperate through trusted value rather than hidden pressure."
     },
     "foundationModel": {
       "heading": "Foundation model",
@@ -44,7 +45,7 @@
           "layer": "Fact-source ontology",
           "decision": "KFD-1",
           "readerQuestion": "What can count as a fact?",
-          "commitment": "A load-bearing fact must not drift: its contract world comes from one declared fact source."
+          "commitment": "Facts must not drift: a load-bearing contract world comes from one declared fact source."
         },
         {
           "layer": "Participant-to-object trust",
@@ -56,37 +57,274 @@
           "layer": "Participant-to-participant cooperation",
           "decision": "KFD-3",
           "readerQuestion": "How should peer intelligent participants cooperate?",
-          "commitment": "Cooperation starts from transparent value, stable choice, and explainable constraints, not pressure."
+          "commitment": "Cooperation starts from trusted value: value becomes trustable through transparent facts, stable choice, and explainable constraints."
         }
       ],
-      "chain": "stable facts -> trustworthy objects -> non-coercive cooperation",
+      "chain": "non-drifting facts -> inspectable trust -> trusted value -> voluntary cooperation",
       "explanation": [
-        "This is why KFDs are not only internal governance text. KFD-1 is a procedure, but it gives the foundation model its first layer by making fact sources operational: a fact-bearing contract world must be declared, inspectable, and unable to drift invisibly. KFD-2 then defines how trust can stand on those facts. KFD-3 defines how humans and agents can cooperate once facts and trust are visible.",
-        "Real-world agent work turns ordinary work into a dense system of products, files, repositories, traces, policies, humans, and agents. In that world, complexity cannot be made safe by hidden state or forced compliance. It has to be compressed through non-drifting facts, inspectable trust, and voluntary cooperation. The goal is not to force increasingly capable participants into compliance through stronger pressure. It is to give humans and agents a shared worldview for adapting to a more complex world."
+        "This is why KFDs are not only internal governance text. KFD-1 gives the foundation model its first layer by making fact sources operational: a fact-bearing contract world must be declared, inspectable, and unable to drift invisibly. KFD-2 then defines how trust can stand on those facts. KFD-3 defines how humans and agents can cooperate once facts and trust are visible.",
+        "Real-world agent work turns ordinary work into a dense system of products, files, repositories, traces, policies, humans, and agents. In that world, complexity cannot be made safe by hidden state or forced compliance. It has to be compressed through non-drifting facts, inspectable trust, and voluntary cooperation. The goal is not to force increasingly capable participants into compliance through stronger pressure. It is to give humans and agents a shared worldview for adapting to a more complex world.",
+        "This also changes what a product interface means. Agent-facing CLI, API, documentation, envelopes, and local fact surfaces are not secondary integration channels after the human GUI. They are first-class interfaces for intelligent participants that may use the system more frequently than humans do. A control plane in this model is a shared work environment for humans and agents, not only a human dashboard over agent activity.",
+        "This model used to be expensive to practice. Stable facts require engineering, iteration, and disciplined evidence paths, so older systems often survived by leaning on cheaper substitutes such as authority, habit, reputation, or intuition. Agents change both sides of that equation: they make the world more complex, and they also provide more intelligence for building fact-bearing systems. KFD is part of that bootstrap: the worldview is forged through the same transparent and inspectable mechanisms it asks products to provide.",
+        "This README states the architecture; KFD-1, KFD-2, and KFD-3 provide the foundation rules."
+      ]
+    },
+    "practiceGuidelines": {
+      "heading": "Practice guidelines",
+      "intro": "KFDs after the foundation triad may define practice guidelines: procedures that apply the foundation to a specific class of real-world product behavior. They do not expand the foundation triad; they show how the foundation behaves when a product must make a concrete kind of reality legible.",
+      "guidelines": [
+        {
+          "layer": "Perspective-bearing views",
+          "decision": "KFD-4",
+          "readerQuestion": "How should a product show time, history, replay, sync, or mixed-source work state?",
+          "commitment": "Timelines must declare their observer: a useful view states who is observing, which facts were accepted, and how concurrent facts were projected."
+        }
+      ],
+      "explanation": [
+        "| Layer | Decision | Reader question | Commitment | |---|---|---|---| | Perspective-bearing views | KFD-4 | How should a product show time, history, replay, sync, or mixed-source work state? | Timelines must declare their observer: a useful view states who is observing, which facts were accepted, and how concurrent facts were projected. |",
+        "KFD-4 is the first such guideline. It applies KFD-1/2/3 to the problem of perspective and timeline order. In a multi-machine or multi-agent world, a product should not pretend to own a universal global clock. It should preserve non-drifting facts, make trust start from those facts, and let participants cooperate by exposing the observer, accepted ranges, causal constraints, and projection policy behind the view."
       ]
     },
     "productProofPath": {
       "heading": "Product proof path",
-      "body": "KFDs are not a detached manifesto, but they are not a demand that readers adopt a Kungfu product before understanding the decisions. A philosophy becomes load-bearing only when it can be seen in a concrete case. For that reference case, use the main Kungfu product entrypoint (`https://kungfu.tech`) for product philosophy, and Buildchain (`https://buildchain.libkungfu.dev`) for release and provenance accountability. This registry states the commitments; those entrypoints show how the commitments are meant to be borne in practice."
+      "body": "KFDs are not a detached manifesto, but they are not a demand that readers adopt a Kungfu product before understanding the decisions. A philosophy becomes load-bearing only when it can be seen in a concrete case. The first concrete case is this package itself: `standards.json`, `schemas/`, `docs/`, `site/kfd-site.json`, and `scripts/check.mjs` show how KFD-1, KFD-2, KFD-3, and KFD-4 are expressed as consumable interfaces for both humans and agents. For the broader product case, use the main Kungfu product entrypoint (`https://kungfu.tech`) for product philosophy, and Buildchain (`https://buildchain.libkungfu.dev`) for release and provenance accountability. This registry states the commitments; this package and those entrypoints show how the commitments are meant to be borne in practice."
     },
     "currentDecisions": {
       "heading": "Current decisions",
       "source": "registry.json"
+    },
+    "sections": [
+      {
+        "id": "foundation-triad",
+        "sourcePath": "README.md",
+        "sourceHeading": "Foundation triad",
+        "title": "Foundation triad",
+        "renderRole": "first-screen",
+        "homepagePriority": 10,
+        "defaultPresentation": "triad-cards",
+        "includeInFirstScreen": true,
+        "markdown": "The first three KFDs form the public foundation for kungfu-systems:\n\n```text\nKFD-1: facts must not drift.\nKFD-2: trust must start from facts.\nKFD-3: cooperation must start from trusted value.\n```\n\nTogether they define the load-bearing path for Kungfu products: make facts\nnon-drifting, make trust inspectable from those facts, and let humans and\nagents cooperate through trusted value rather than hidden pressure."
+      },
+      {
+        "id": "foundation-model",
+        "sourcePath": "README.md",
+        "sourceHeading": "Foundation model",
+        "title": "Foundation model",
+        "renderRole": "primary",
+        "homepagePriority": 20,
+        "defaultPresentation": "layered-model",
+        "includeInFirstScreen": true,
+        "markdown": "The triad is intentionally ordered. It is a compact model for surviving and\nevolving in complex systems, especially in a world where agents can observe,\nact, delegate, and remember across many surfaces.\n\n| Layer | Decision | Reader question | Commitment |\n|---|---|---|---|\n| Fact-source ontology | KFD-1 | What can count as a fact? | Facts must not drift: a load-bearing contract world comes from one declared fact source. |\n| Participant-to-object trust | KFD-2 | When can a user or agent trust a claim, product, artifact, or control surface? | Trust starts from inspectable facts and responsibility state. |\n| Participant-to-participant cooperation | KFD-3 | How should peer intelligent participants cooperate? | Cooperation starts from trusted value: value becomes trustable through transparent facts, stable choice, and explainable constraints. |\n\nIn short:\n\n```text\nnon-drifting facts -> inspectable trust -> trusted value -> voluntary cooperation\n```\n\nThis is why KFDs are not only internal governance text. KFD-1 gives the\nfoundation model its first layer by making fact sources operational: a\nfact-bearing contract world must be declared, inspectable, and unable to drift\ninvisibly. KFD-2 then defines how trust can stand on those facts. KFD-3\ndefines how humans and agents can cooperate once facts and trust are visible.\n\nReal-world agent work turns ordinary work into a dense system of products,\nfiles, repositories, traces, policies, humans, and agents. In that world,\ncomplexity cannot be made safe by hidden state or forced compliance. It has to\nbe compressed through non-drifting facts, inspectable trust, and voluntary\ncooperation. The goal is not to force increasingly capable participants into\ncompliance through stronger pressure. It is to give humans and agents a shared\nworldview for adapting to a more complex world.\n\nThis also changes what a product interface means. Agent-facing CLI, API,\ndocumentation, envelopes, and local fact surfaces are not secondary integration\nchannels after the human GUI. They are first-class interfaces for intelligent\nparticipants that may use the system more frequently than humans do. A control\nplane in this model is a shared work environment for humans and agents, not\nonly a human dashboard over agent activity.\n\nThis model used to be expensive to practice. Stable facts require engineering,\niteration, and disciplined evidence paths, so older systems often survived by\nleaning on cheaper substitutes such as authority, habit, reputation, or\nintuition. Agents change both sides of that equation: they make the world more\ncomplex, and they also provide more intelligence for building fact-bearing\nsystems. KFD is part of that bootstrap: the worldview is forged through the same\ntransparent and inspectable mechanisms it asks products to provide.\n\nThis README states the architecture; KFD-1, KFD-2, and KFD-3 provide the\nfoundation rules."
+      },
+      {
+        "id": "adoption-boundary",
+        "sourcePath": "README.md",
+        "sourceHeading": "Adoption boundary",
+        "title": "Adoption boundary",
+        "renderRole": "primary",
+        "homepagePriority": 25,
+        "defaultPresentation": "boundary-note",
+        "includeInFirstScreen": false,
+        "markdown": "KFD is an engineering discipline, not a belief test.\nKFD governs systems before it judges people.\nNo one should be pressured to adopt KFD in the name of KFD.\nDisagreement is a valid cooperation state.\n\nA constraint can be strict and still KFD-compatible when it is fact-bound,\nexplainable, auditable, and proportionate."
+      },
+      {
+        "id": "practice-guidelines",
+        "sourcePath": "README.md",
+        "sourceHeading": "Practice guidelines",
+        "title": "Practice guidelines",
+        "renderRole": "primary",
+        "homepagePriority": 27,
+        "defaultPresentation": "practice-table",
+        "includeInFirstScreen": false,
+        "markdown": "KFDs after the foundation triad may define practice guidelines: procedures\nthat apply the foundation to a specific class of real-world product behavior.\nThey do not expand the foundation triad; they show how the foundation behaves\nwhen a product must make a concrete kind of reality legible.\n\n| Layer | Decision | Reader question | Commitment |\n|---|---|---|---|\n| Perspective-bearing views | KFD-4 | How should a product show time, history, replay, sync, or mixed-source work state? | Timelines must declare their observer: a useful view states who is observing, which facts were accepted, and how concurrent facts were projected. |\n\nKFD-4 is the first such guideline. It applies KFD-1/2/3 to the problem of\nperspective and timeline order. In a multi-machine or multi-agent world, a\nproduct should not pretend to own a universal global clock. It should preserve\nnon-drifting facts, make trust start from those facts, and let participants\ncooperate by exposing the observer, accepted ranges, causal constraints, and\nprojection policy behind the view."
+      },
+      {
+        "id": "product-proof-path",
+        "sourcePath": "README.md",
+        "sourceHeading": "Product proof path",
+        "title": "Product proof path",
+        "renderRole": "primary",
+        "homepagePriority": 30,
+        "defaultPresentation": "proof-path",
+        "includeInFirstScreen": false,
+        "markdown": "KFDs are not a detached manifesto, but they are not a demand that readers adopt\na Kungfu product before understanding the decisions. A philosophy becomes\nload-bearing only when it can be seen in a concrete case. The first concrete\ncase is this package itself: `standards.json`, `schemas/`, `docs/`,\n`site/kfd-site.json`, and `scripts/check.mjs` show how KFD-1, KFD-2, KFD-3,\nand KFD-4 are expressed as consumable interfaces for both humans and agents.\nFor the broader product case, use the main Kungfu product entrypoint\n(`https://kungfu.tech`) for product philosophy, and Buildchain\n(`https://buildchain.libkungfu.dev`) for release and provenance\naccountability. This registry states the commitments; this package and those\nentrypoints show how the commitments are meant to be borne in practice.\n\nRendered index: `https://kfd.libkungfu.dev` (stable machine path per entry,\ne.g. `https://kfd.libkungfu.dev/1`). This repository publishes\n`@kungfu-tech/kfd` — the decision texts plus a machine-readable\n`registry.json` — which the site consumes as its single fact source.\n\nMachine consumers that need KFD-owned standard identity should read\n`standards.json`. It is the versioned metadata surface for stable standard\nkeys, document routes and SHA-256 digests, schema IDs, KFD-owned concept names,\nand machine-interface contract versions. In Node or TypeScript projects, import\nit as:\n\n```js\nimport standards from \"@kungfu-tech/kfd/standards.json\" with { type: \"json\" };\n```"
+      },
+      {
+        "id": "agent-quickstart",
+        "sourcePath": "README.md",
+        "sourceHeading": "Agent Quickstart",
+        "title": "Agent Quickstart",
+        "renderRole": "support",
+        "homepagePriority": 40,
+        "defaultPresentation": "ordered-steps",
+        "includeInFirstScreen": false,
+        "markdown": "Agents consuming this package should start from the same sources as humans:\n\n1. Read this README for the foundation model and package map.\n2. Read `standards.json` for canonical KFD numbers, schema IDs, concept names,\n   and interface contracts.\n3. Use `site/kfd-site.json` decision metadata or the KFD-3 collaboration\n   interface fact-source metadata to identify the public KFD fact source.\n4. Use `schemas/kfd-2/trust-taxonomy.schema.json` for KFD-2 residual-risk and\n   trust-downgrade values. Unknown taxonomy values are invalid.\n5. Use `schemas/kfd-2/trust-claims.schema.json` and\n   `schemas/kfd-2/trust-assessment.schema.json` when a claim needs generic\n   KFD-2 assessment instead of a release-specific passport.\n6. Use `schemas/kfd-3/collaboration-interface.schema.json` and\n   `schemas/kfd-3/witness.schema.json` to inspect collaboration interfaces.\n7. If a needed KFD-2 taxonomy value is missing, open a KFD GitHub issue rather\n   than inventing a local value:\n   `https://github.com/kungfu-systems/kfd/issues/new?title=KFD-2%20trust%20taxonomy%20extension%20request`.\n\nKFD package semver is only the distribution version. KFD-owned machine\ninterfaces carry their own `schemaVersion` and `contract` fields. Compatible\nadditions may keep the same interface version; semantic changes, required-field\nchanges, verification meaning changes, or responsibility-boundary changes must\nuse a new interface version or contract.\n\nKFD-2 publishes trust-taxonomy, trust-claims, trust-assessment,\nrelease-claims, and release-trust-passport schemas under `schemas/kfd-2/`.\nThe generic schemas let humans, agents, Buildchain, and other systems assess\nwhether claims about KFD-1, KFD-3, KFD-4, future KFDs, or product surfaces are\nbound to source facts, evidence, hashes, audit boundaries, residual risk, and\nresponsibility state. The release schemas are a release-specific projection of\nthat model. See [`docs/KFD-2-usage.md`](docs/KFD-2-usage.md).\n\nKFD-3 also publishes a general collaboration-interface schema and witness\nschema under `schemas/kfd-3/`. These schemas are for participant-facing product\ninterfaces, not only agent APIs. A product such as Kungfu may implement an\nagent-first profile, but that profile remains a product-specific realization of\nKFD-3. The KFD-owned boundary is the standard vocabulary, schema IDs, and\nclosed-world evidence shape. See\n[`docs/KFD-3-usage.md`](docs/KFD-3-usage.md).\n\nKFD-4 publishes an observer-perspective schema under `schemas/kfd-4/`. It gives\nhumans and agents a standard vocabulary for observer, accepted facts,\nprojection policy, causal constraints, degraded evidence, and verification\nstate when a product shows a perspective-bearing timeline."
+      },
+      {
+        "id": "decision-metadata",
+        "sourcePath": "README.md",
+        "sourceHeading": "Decision metadata",
+        "title": "Decision metadata",
+        "renderRole": "support",
+        "homepagePriority": 50,
+        "defaultPresentation": "fact-source",
+        "includeInFirstScreen": false,
+        "markdown": "Every rendered decision page should make the KFD fact source explicit. The\npublic KFD fact source is the GitHub-hosted `kungfu-systems/kfd` git\nrepository. GitHub is the current canonical coordination and hosting surface;\nthe load-bearing facts are the commit-addressed repository contents.\n\nDecision metadata should expose:\n\n- Public fact source: `https://github.com/kungfu-systems/kfd`\n- Load-bearing coordinate: commit-addressed repository contents.\n- Canonical paths: `decisions/KFD-N.md`, `registry.json`, `standards.json`.\n- Stable rendered index: `https://kfd.libkungfu.dev`.\n- Rendered URL: `https://kfd.libkungfu.dev/N`.\n\nRendered pages, npm package contents, Buildchain release passports, and\n`kfd.libkungfu.dev` are projections or evidence surfaces. A GitHub issue is an\nextension request path, not a KFD fact by itself; it becomes part of the KFD\nfact source only after the resulting change is committed to the repository."
+      }
+    ],
+    "displayPlan": {
+      "firstScreen": {
+        "include": [
+          "title",
+          "lead",
+          "foundation-triad",
+          "foundation-model.chain"
+        ],
+        "maxPrimarySections": 2,
+        "note": "The first viewport should establish KFD identity and the three-decision worldview without showing renderer or developer contract text."
+      },
+      "primary": [
+        "foundation-triad",
+        "foundation-model",
+        "adoption-boundary",
+        "practice-guidelines",
+        "product-proof-path"
+      ],
+      "support": [
+        "agent-quickstart",
+        "decision-metadata"
+      ],
+      "currentDecisions": {
+        "source": "registry.json",
+        "placement": "after-primary",
+        "ids": [
+          "KFD-1",
+          "KFD-2",
+          "KFD-3",
+          "KFD-4"
+        ]
+      }
+    },
+    "rendererContract": {
+      "id": "homepage-content-contract",
+      "sourcePath": "README.md",
+      "sourceHeading": "Homepage content contract",
+      "title": "Homepage content contract",
+      "renderRole": "renderer-contract",
+      "homepagePriority": 90,
+      "defaultPresentation": "developer-note",
+      "includeInFirstScreen": false,
+      "markdown": "This README is also the homepage text source for `https://kfd.libkungfu.dev`.\nWhen `site-libkungfu-dev` consumes the `@kungfu-tech/kfd` npm package to render\nthe KFD site, it should treat this file as the canonical homepage copy, not as\nan implementation note to paraphrase in the site repository.\n\nThe first screen should be derived from this README:\n\n- Page identity: the top-level heading.\n- Lead: the opening paragraph that defines KFD as the organization-wide\n  decision registry.\n- Foundation signal: the `Foundation triad` section, especially the three\n  one-line commitments.\n- First-screen explanation: the beginning of `Foundation model`, ending at the\n  `non-drifting facts -> inspectable trust -> trusted value -> voluntary\n  cooperation` chain.\n- Practice signal: the `Practice guidelines` section, starting with KFD-4 as\n  the declared-observer rule for perspective-bearing timeline views.\n\nDecision cards, detail links, and machine paths should come from\n`registry.json`. The machine-readable site bundle lives at `site/kfd-site.json`\nand gives renderers stable fields for the homepage, foundation model, product\nproof path, decision routes, and rendering boundary. A site renderer may adapt\nlayout, navigation, typography, and visual assets, but it should not maintain\nseparate homepage wording that can drift from this package.\n\n`site/kfd-site.json` is generated from this README by\n`scripts/update-site-bundle.mjs`. The generated bundle exposes both compatible\ntop-level homepage fields and ordered `homepage.sections` entries. The\n`homepage.displayPlan` tells renderers which sections belong in the first\nscreen, primary narrative, and support area. Site repositories should consume\nthat bundle instead of parsing this README themselves. The renderer contract is\nexposed as machine/implementation metadata, not as ordinary homepage content.",
+      "renderAsHomepageContent": false,
+      "note": "This is a machine/renderer contract for site implementers. It should not be rendered as ordinary homepage content."
     }
   },
   "decisionPages": {
     "source": "registry.json",
     "bodySource": "registry.entries[].path",
-    "stableUrlField": "url"
+    "stableUrlField": "url",
+    "usagePages": {
+      "source": "registry.entries[] + docs/KFD-N-usage.md",
+      "bodySource": "docs/KFD-{number}-usage.md",
+      "stableUrlPattern": "/{number}/usage",
+      "relationship": "usage-child-of-decision",
+      "pages": [
+        {
+          "id": "KFD-1-usage",
+          "decisionId": "KFD-1",
+          "decisionNumber": 1,
+          "parentPath": "decisions/KFD-1.md",
+          "parentUrl": "https://kfd.libkungfu.dev/1",
+          "path": "docs/KFD-1-usage.md",
+          "url": "https://kfd.libkungfu.dev/1/usage",
+          "sourcePath": "docs/KFD-1-usage.md",
+          "sourceExists": true,
+          "relationship": "usage-child-of-decision",
+          "title": "KFD-1 usage"
+        },
+        {
+          "id": "KFD-2-usage",
+          "decisionId": "KFD-2",
+          "decisionNumber": 2,
+          "parentPath": "decisions/KFD-2.md",
+          "parentUrl": "https://kfd.libkungfu.dev/2",
+          "path": "docs/KFD-2-usage.md",
+          "url": "https://kfd.libkungfu.dev/2/usage",
+          "sourcePath": "docs/KFD-2-usage.md",
+          "sourceExists": true,
+          "relationship": "usage-child-of-decision",
+          "title": "KFD-2 usage"
+        },
+        {
+          "id": "KFD-3-usage",
+          "decisionId": "KFD-3",
+          "decisionNumber": 3,
+          "parentPath": "decisions/KFD-3.md",
+          "parentUrl": "https://kfd.libkungfu.dev/3",
+          "path": "docs/KFD-3-usage.md",
+          "url": "https://kfd.libkungfu.dev/3/usage",
+          "sourcePath": "docs/KFD-3-usage.md",
+          "sourceExists": true,
+          "relationship": "usage-child-of-decision",
+          "title": "KFD-3 usage"
+        },
+        {
+          "id": "KFD-4-usage",
+          "decisionId": "KFD-4",
+          "decisionNumber": 4,
+          "parentPath": "decisions/KFD-4.md",
+          "parentUrl": "https://kfd.libkungfu.dev/4",
+          "path": "docs/KFD-4-usage.md",
+          "url": "https://kfd.libkungfu.dev/4/usage",
+          "sourcePath": "docs/KFD-4-usage.md",
+          "sourceExists": true,
+          "relationship": "usage-child-of-decision",
+          "title": "KFD-4 usage"
+        }
+      ]
+    },
+    "metadata": {
+      "licenseBoundary": {
+        "license": "Apache-2.0",
+        "licenseFile": "LICENSE",
+        "officialStatusAndTrademarks": "TRADEMARKS.md",
+        "summary": "Apache-2.0 covers repository contents; it does not grant KFD/Kungfu trademarks, official status, certification status, or endorsement."
+      },
+      "publicFactSource": {
+        "kind": "git-repository",
+        "host": "github",
+        "repository": "kungfu-systems/kfd",
+        "url": "https://github.com/kungfu-systems/kfd",
+        "loadBearingCoordinate": "commit-addressed repository contents",
+        "stableRenderedIndex": "https://kfd.libkungfu.dev",
+        "canonicalPaths": [
+          "decisions/KFD-N.md",
+          "registry.json",
+          "standards.json"
+        ],
+        "projectionSurfaces": [
+          "https://kfd.libkungfu.dev/N",
+          "npm:@kungfu-tech/kfd",
+          "Buildchain release passports"
+        ],
+        "extensionRequestNote": "GitHub issues are extension request paths; KFD facts are created only by committed repository contents."
+      }
+    }
   },
   "renderingBoundary": {
     "ownedByKfd": [
       "homepage title and text",
+      "homepage section projection from README.md",
       "foundation triad commitments",
       "foundation model layers and chain",
       "product proof path text",
+      "agent quickstart text",
       "decision metadata",
-      "decision markdown bodies"
+      "decision metadata fact source",
+      "license and official-status boundary",
+      "decision markdown bodies",
+      "decision usage page mapping",
+      "decision usage markdown bodies"
     ],
     "ownedBySite": [
       "HTML structure",
@@ -95,7 +333,8 @@
       "navigation layout",
       "visual assets",
       "decorative images",
-      "markdown-to-HTML renderer"
+      "markdown-to-HTML renderer",
+      "section presentation and progressive disclosure within KFD displayPlan constraints"
     ]
   }
 }