Lab: from plugins to a shippable product
Use packages, bundles, profiles, contract tests, and source snapshots to turn extensions into a maintainable product
package → bundle → profile → releaseWhat boundaries separate a locally working plugin from a shippable product?
Inventing a part is not shipping a product. You still need specifications, assembly manifests, compatible versions, acceptance tests, upgrade notes, and a recall path.
Mechanism
Features separate Service Definition, provider, consumer, and policy packages. Bundles provide patchable config, profiles name product compositions, and user patches preserve local differences.
Developer preview means breaking change is normal. Teaching and extension projects should pin an upstream commit, keep a source map, use contract tests, and audit diffs regularly.
Define package boundary
Export stable vocabulary and avoid reverse dependencies.
What extensions must preserve
- Product defaults are explainable with --dump-config
- User customization survives as upper-layer patches
- Teaching claims name the upstream snapshot and inference boundary
The tempting wrong turns
- ×Hardcoding example config into providers
- ×Publishing a bundle that requires source edits
- ×Showing stale event ordering after upstream breaking changes
Do not trust the conclusion—verify it
These anchors are pinned to official deepseek-harness@47f9438; account for later breaking changes when reading current upstream.
docs/cookbook/extension-cookbook.mdTask map from capability to packages, tools, adapters, and clients.
docs/cookbook/adding-a-package.mdPackage structure, exports, and verification.
docs/development.mdOfficial development commands and quality gates.
Pause for ten seconds before revealing
Why must this learning project record an upstream commit instead of saying latest?
You now have an end-to-end path from mental model and composition through runtime, safety, durability, and extension delivery. Keep the architecture atlas and source index as daily references.