# Kungfu UNGFU™ — Developer Platform libkungfu.dev is the open developer and agent substrate hub for Kungfu. Brand boundary: Kungfu is the product name. UNGFU is not a second product or runtime, and the trademark symbol makes no registration-status claim. Reader contract: libkungfu-dev-reader-contract/v1 Orient first, synthesize second, hand off to upstream authority third, and expose machine evidence throughout. Reader layers: - First-screen proposition [site-libkungfu-dev]: Answer why this surface matters to its intended reader before status, registry, or implementation detail. - Guided synthesis [site-libkungfu-dev]: Connect facts across Kungfu, KFD, and Buildchain without turning the synthesis into a new normative source. - Upstream authority [kungfu-systems/kungfu, @kungfu-tech/kfd, and @kungfu-tech/buildchain]: Supply runtime semantics, protocol decisions, schemas, commands, workflows, and release facts. - Machine evidence [upstream authorities projected by site-libkungfu-dev]: Expose exact sources, versions, digests, qualification, claim boundaries, and stable routes for independent inspection. Installed Kungfu Agent Hub qualification: - Human guide: https://kfd.libkungfu.dev/agent-hub/ - Run: kungfu agent hub qualify --output-dir - Verify: kungfu agent hub verify --qualification-dir - Ownership: KFD owns the fixed suite and offline report verifier; Kungfu owns its product semantics, isolated execution, installed-artifact binding, and human or agent explanation. - Claim boundary: Demo success and generated starter smoke success are non-qualifying, non-certifying evidence. Only kfd test agent-hub executes Hub 20 against the named adapter artifact. Kungfu may project that report into an exact installed-product qualification, but it does not turn the result into KFD certification, a security assessment, production fitness, remote-network interoperability, or external adoption. Guided synthesis: Long-running Agent work needs a continuity stack, not one longer session. A session is a useful interaction boundary. It is not enough to preserve admitted state, causal experience, continuing responsibility, or an accepted project result across agents, machines, repositories, and days. - Fact + Episode [site-synthesis]: A Fact Cut preserves admitted state. An Episode preserves the causal worldline that actually occurred between cuts. Sources: kungfu-action-runtime, kfd-7 - Pursuit + Atlas + Warrant [site-synthesis]: Direction, declared perspective, and bounded authority remain independently addressable before action is treated as responsible. Sources: kungfu-action-runtime, kfd-7 - Initiative + Assignment [site-synthesis]: The Agent Work profile organizes continuing change and bounded responsibility without redefining the lower cross-domain coordinates. Sources: kungfu-project-cut-loop - Settlement → Project Cut [site-synthesis]: Evidence crosses the admission boundary only through explicit settlement; the resulting Project Cut states what the project has officially become. Sources: kungfu-project-cut-loop - The protocol removes shared-infrastructure assumptions. [site-synthesis]: KFD does not require every participant to share one implementation. It preserves the minimum responsibility semantics needed for independent systems to cooperate without guessing. Sources: kfd-agent-hub-profile, kfd-3 Agent supply chain: Hub vendors keep the commercially valuable product layer. KFD defines portable cooperation boundaries, libkungfu preserves local runtime facts and Episodes, and Buildchain binds shipped claims to exact artifacts. - Hub [Each vendor; site-synthesis]: UI, models, accounts, billing, cloud, policy, and customer relationships remain with the Hub owner. Sources: kfd-agent-hub-profile, kfd-3 - KFD [Open protocol; future-picture]: Independent Hubs can exchange bounded responsibility without adopting one control plane or one mandatory cloud. Sources: kfd-agent-hub-profile - libkungfu [Local runtime; reference-implementation]: The reference runtime preserves admitted Facts, causal Episodes, recovery, and inspectable projections below the Hub product. Sources: kungfu-action-runtime - Buildchain [Release trust; upstream-fact]: Release passports keep product claims congruent with exact source, artifacts, verification, provenance, and promotion evidence. Sources: buildchain-release-passport, buildchain-kfd-support, kfd-2 - Claim boundary [non-claim]: The KFD Agent Hub profile is alpha. It defines an interoperability contract; it does not prove external vendor adoption, plural-Hub deployment, stable certification, or an industry standard. Buildchain reader synthesis: Buildchain turns release work into a Hub admission surface. A Hub can accept more capability without inheriting blind trust. Buildchain turns a Builder's public offer and its supporting facts into one release-bound surface that the Hub can evaluate under its own policy. - KFD-3 declares the value. KFD-2 makes it trustable. Buildchain binds both to the release. [site-synthesis]: Discovery alone leaves a Hub with marketing claims. Evidence alone leaves useful capability hidden in private release machinery. The two become an adoption surface only when the offer and its trust boundary travel together. Sources: buildchain-release-passport, buildchain-kfd-support, kfd-2, kfd-3 - KFD-3 / Declare the offer [site-synthesis]: The Builder exposes what the product can do, why it is useful, which public surfaces carry it, and which choices and constraints apply. Sources: kfd-3, buildchain-kfd-support - KFD-2 / Assess reliance [site-synthesis]: Each important value claim binds to inspectable facts, checked evidence, assurance responsibility, known gaps, and residual risk. Sources: kfd-2, buildchain-kfd-support - Buildchain / Bind the exact release [site-synthesis]: The Release Passport keeps the claim congruent with exact source, artifacts, verification, provenance, and promotion evidence. Sources: buildchain-release-passport, buildchain-kfd-support - Builder Hub / Keep the verdict local [site-synthesis]: The receiving Hub evaluates that exact release under its own identity, authority, policy, and risk boundary; discovery or delivery never forces admission. Sources: kfd-agent-hub-profile, kfd-2 - What a Builder Hub gains [site-synthesis]: Buildchain lowers the marginal cost of extending a Hub without turning a third-party integration into an invisible transfer of trust or product control. Sources: buildchain-release-passport, buildchain-kfd-support, kfd-2, kfd-3, kfd-agent-hub-profile - More capability, less blind trust [site-synthesis]: Expand the capability supply while keeping important reliance claims inspectable and bounded. Sources: kfd-2, kfd-3 - Reusable admission [site-synthesis]: Evaluate a declared capability and its evidence instead of reconstructing a bespoke trust story for every integration. Sources: buildchain-kfd-support, kfd-2, kfd-3 - Reviewable evolution [site-synthesis]: Treat an update as a new exact release and evidence coordinate that can be reassessed, explained, or rolled back. Sources: buildchain-release-passport, kfd-2 - The moat stays above [site-synthesis]: Share the trust substrate while differentiating through models, policy, user experience, distribution, and the customer relationship. Sources: kfd-agent-hub-profile, kfd-3 - A portable trust surface can compound across an ecosystem. [future-picture]: When Builders publish the same release-bound capability and trust facts that Hubs can evaluate locally, one integration can become reusable supply instead of a one-off bilateral trust exercise. Sources: buildchain-release-passport, buildchain-kfd-support, kfd-2, kfd-3, kfd-agent-hub-profile - Publish once per release [future-picture]: A Builder declares public capability surfaces and their evidence against one exact artifact coordinate. Sources: buildchain-release-passport, buildchain-kfd-support - Assess under local policy [future-picture]: Each Hub keeps its own acceptance verdict; compatibility never transfers approval, authority, or responsibility. Sources: kfd-agent-hub-profile, kfd-2 - Compound reusable supply [future-picture]: More release-bound offers can lower the marginal cost of publishing and admitting capabilities across independently owned Hubs. Sources: kfd-3, kfd-agent-hub-profile - Claim boundary [non-claim]: This is the ecosystem effect enabled by the contract, not evidence of a present network effect. The KFD Agent Hub profile is alpha and does not prove external adoption, plural-Hub deployment, stable certification, or an industry standard. Sources: kfd-agent-hub-profile - Your Hub remains yours. [site-synthesis]: Buildchain is a public release-trust layer below the Hub product. It does not become the Hub, a marketplace, a global identity provider, a mandatory cloud, or a channel into the Builder's customer relationship. Sources: buildchain-release-passport, kfd-agent-hub-profile - Retained by the Hub: Users and customer relationships; Accounts and billing; Models and Agents; UI and product experience; Cloud and storage; Identity and policy; Admission and revocation Surface reading paths: - hub / Agent product builders: How do you add durable Agent continuity without giving up your Hub? Keep the product and customer relationship. Adopt only the portable runtime and cooperation layers you need. - core / Kungfu adopters and runtime builders: Which Kungfu layer solves the continuity problem I have now? Start with the complete product map, adopt only the layer you need, and inspect every maturity and authority boundary. - kfd / Protocol builders: How can independent systems cooperate without sharing a control plane? Start with KFD's continuity question and adoption boundary, then descend into the numbered authority, schemas, and exact decision text. - buildchain / Agent product and Hub builders: How can your Hub accept more capability without inheriting blind trust? Bind KFD-3 value surfaces and KFD-2 trust evidence to exact releases while keeping your product, customer relationship, and local admission policy. Primary pages: - https://libkungfu.dev/ - https://libkungfu.dev/architecture/ (complete continuity architecture) - https://libkungfu.dev/dogfood/ - https://core.libkungfu.dev/ - https://core.libkungfu.dev/runtime/ (complete runtime mechanism) - https://buildchain.libkungfu.dev/ - https://buildchain.libkungfu.dev/mechanism/ (complete release-trust mechanism) - https://kfd.libkungfu.dev/ - https://kfd.libkungfu.dev/decisions/ (complete decisions and standards) - https://papers.libkungfu.dev/ - https://papers.libkungfu.dev/archive/ (publication evidence) Machine entries: - https://libkungfu.dev/manifest.json - https://libkungfu.dev/runtime.json - https://libkungfu.dev/agent-supply-chain.json - https://libkungfu.dev/dogfood-evidence.json - https://libkungfu.dev/llms.txt - https://libkungfu.dev/llms-full.txt - https://core.libkungfu.dev/manifest.json - https://core.libkungfu.dev/site-bundle.json - https://core.libkungfu.dev/agent-index.json - https://core.libkungfu.dev/adr-map.json - https://core.libkungfu.dev/llms.txt - https://papers.libkungfu.dev/manifest.json - https://papers.libkungfu.dev/registry.json Core product promise: Kungfu helps a fresh agent continue the same real-world work without asking you to explain it all again. Core product routes: - / Product map [coming-soon] - /format/ .kungfu [staged] - /primitives/ Fact, Episode and Action Geometry [qualified-shadow] - /runtime/ Runtime [qualified] - /abi/ Native ABI [qualified] - /sdk/ SDKs [staged] - /extensions/ KFX and Domain Profiles [staged] - /products/ CLI, TUI, GUI and App [coming-soon] - /qualification/ Qualification and release [staged] - /decisions/ ADR map [implemented] - /horizons/ Domain horizons [current-focus] Agent Supply Chain: 1. kfd-3 [proved-now] - Discover how products cooperate through inspectable value, constraints, choices, commands, Exit, and records. 2. buildchain [proved-now] - Bind product-owned declarations to exact source, build, artifact, checks, and promotion evidence. 3. kfd-2 [proved-now] - Assess claims for a declared purpose while retaining residual risk and decision ownership. 4. libkungfu [proved-now] - Preserve admitted work facts, Episodes, roots, export, and recovery evidence while applications own domain facts. 5. agent-hub-portability [enabled-by-protocol] - Carry bounded responsibility objects across independently owned products with receiver-owned admission. Claim boundary: Kungfu does not claim that a multi-Hub ecosystem already exists. It proves that Agent discovery, software provenance, trust, durable work state, and portability no longer need to be rebuilt or locked inside each Hub. Vendor next action: Assign a technical and product owner, run a bounded 30-day assessment, build one adapter or conformance spike, submit protocol gaps, then decide to adopt, co-shape, or monitor. Source boundary: This repository owns the reader contract and renders pinned upstream evidence, manifests, and packages. It is not a product fact source. Embeddable runtime facts come from the pinned Kungfu source/PR and KFD Runtime 100 roots in /runtime.json. The complete Core product map comes from the exact @kungfu-tech/site bundle, including its per-surface maturity, authority, and non-claim boundaries. Buildchain facts must come from the @kungfu-tech/buildchain docs/site bundle. KFD facts must come from the @kungfu-tech/kfd site bundle, registry, and decision documents. Publication archive facts must come from Buildchain publication registry data.