feat: publish Dever core with project scaffolding and versioned AI skills
This commit is contained in:
1 parent
70fa73cdc2
commit
ac458ffa7f
960 files changed
+221319
-1163
No files matched your search
@@ -0,0 +1,51 @@
|
||||
# Package Distribution Research
|
||||
|
||||
## Question
|
||||
|
||||
How should a Dever project consume a component downloaded from GitHub or another Git host without leaking transport details into `.dever` source or losing reproducible builds?
|
||||
|
||||
## Primary Evidence
|
||||
|
||||
- Go defines a module as a versioned collection of packages. The module path is also the prefix of package import paths and usually identifies where the module can be downloaded. Downloaded source is shared through a module cache, and hashes are verified against `go.sum`.
|
||||
- https://go.dev/ref/mod
|
||||
- https://go.dev/doc/modules/gomod-ref
|
||||
- Cargo permits registry, Git and local path sources. Git dependencies may select a tag or revision, and Cargo locks the resolved commit in `Cargo.lock` until an explicit update.
|
||||
- https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html
|
||||
- Cargo and Go both separate downloaded source caches from project build artifacts. Go also supports optional vendoring for a fully project-local source tree.
|
||||
- https://go.dev/ref/mod#module-cache
|
||||
- https://go.dev/ref/mod#vendoring
|
||||
- https://doc.rust-lang.org/cargo/reference/config.html#cache
|
||||
|
||||
## Alternatives
|
||||
|
||||
### Git URL as package identity
|
||||
|
||||
Example: `github.com.shemic.contact.phone.parse(raw)`.
|
||||
|
||||
This is easy to locate but couples every source reference and type identity to the current hosting provider. Repository transfer, self-hosting or registry mirroring then becomes a source-breaking rename. It also creates long names that obscure the business API.
|
||||
|
||||
### Project-local copied dependencies
|
||||
|
||||
Example: clone every dependency under `vendor/`.
|
||||
|
||||
This is transparent and offline-friendly but duplicates source across projects, increases repository size and makes accidental dependency edits likely. It is useful as an explicit export mode, not the default store.
|
||||
|
||||
### Stable identity plus independent source
|
||||
|
||||
Example identity: `shemic.contact`; example source: `https://github.com/shemic/contact.git` at an exact resolved commit.
|
||||
|
||||
This preserves short, stable `.dever` names while allowing registry, Git, mirrors and local development to use the same package identity. It requires dependency metadata and identity verification, but those responsibilities belong to the package manager rather than business source.
|
||||
|
||||
## Recommendation
|
||||
|
||||
Use the third model:
|
||||
|
||||
1. `component id` is the stable namespace and type-identity root.
|
||||
2. `source` is a replaceable registry, Git or local transport selected outside `.dever`.
|
||||
3. `dever.mod` records direct dependency intent and source requirements.
|
||||
4. `dever.lock` records the complete graph, full Git commits and normalized content hashes.
|
||||
5. A global immutable content-addressed store deduplicates verified source across projects.
|
||||
6. `check`, `build` and `run` never perform implicit network access; explicit `add`, `update` and `fetch` do.
|
||||
7. Package declarations must remain beneath the component root, preventing one dependency from supplying another component's namespace.
|
||||
|
||||
This deliberately combines Go's small module/package model and shared verified cache with Cargo's source flexibility and exact Git locking, while avoiding Go's coupling between source-level identity and repository location.
|
||||
@@ -0,0 +1,55 @@
|
||||
# Core 0.1 Runtime Dependency Research
|
||||
|
||||
- Checked: 2026-09-03
|
||||
- Scope: dependencies required by already-approved Decimal and Map semantics
|
||||
|
||||
## Decimal128
|
||||
|
||||
Selected for the MVP: `dec = "=0.4.11"`.
|
||||
|
||||
Evidence:
|
||||
|
||||
- The [dec crate documentation](https://docs.rs/dec/latest/dec/) describes `Decimal128` as a 128-bit decimal representation with 34 digits of precision and exposes a configurable `Context` with rounding and exceptional-condition status.
|
||||
- The [Decimal128 API](https://docs.rs/dec/latest/dec/struct.Decimal128.html) supports the required arithmetic and classification operations.
|
||||
|
||||
Reason:
|
||||
|
||||
- It directly implements the approved decimal128 contract instead of approximating it with a lower-precision financial decimal.
|
||||
- Context status lets Dever convert overflow, division by zero and invalid Decimal states into language-level runtime faults.
|
||||
- A reusable Context avoids the per-operation default-context overhead documented by the crate.
|
||||
|
||||
Constraint:
|
||||
|
||||
- `dec` is a safe Rust wrapper over libdecnumber and therefore introduces a native C build dependency. It must remain isolated behind `dever_runtime::number::DecimalValue`.
|
||||
- Dever conformance tests, not the crate's operator defaults or special-value surface, define public behavior.
|
||||
- A future pure-Rust replacement is allowed only when it passes the same conformance suite; this does not change `.dever` semantics.
|
||||
|
||||
Rejected for Core 0.1:
|
||||
|
||||
- `rust_decimal`: pure Rust, but its 96-bit coefficient does not provide the approved 34-digit decimal128 contract.
|
||||
- Hand-written decimal arithmetic: correct rounding, exponent handling and status behavior are too risky for the language MVP.
|
||||
- Newly published decimal128 implementations: potentially useful later, but less established than the selected reference implementation.
|
||||
|
||||
## Insertion-Ordered Map
|
||||
|
||||
Selected for the MVP: `indexmap = "=2.14.0"`.
|
||||
|
||||
Evidence:
|
||||
|
||||
- The [IndexMap project](https://github.com/indexmap-rs/indexmap) documents hash-based lookup with iteration independent of hash order.
|
||||
- The [IndexMap API](https://docs.rs/indexmap/latest/indexmap/map/struct.IndexMap.html) documents that insertion appends new keys, overwriting preserves the existing position, and order-preserving removal is available.
|
||||
|
||||
Reason:
|
||||
|
||||
- Those operations match the approved Dever Map contract without maintaining a duplicate vector-plus-index implementation.
|
||||
- Lookup remains hash based while iteration is deterministic.
|
||||
|
||||
Constraint:
|
||||
|
||||
- Dever wraps IndexMap and exposes only `get`, `put`, `remove` and `entries`.
|
||||
- Removal uses the order-preserving operation rather than swap removal.
|
||||
- Dependency-specific index access never appears in `.dever` or public diagnostics.
|
||||
|
||||
## Dependency Discipline
|
||||
|
||||
These are planned pins; the initial parser milestone has no external dependencies. Verify availability and pin each version when the runtime first consumes it. No dependency becomes a public language contract. Upgrading either dependency requires running the focused Decimal/Map conformance tests and confirming that serialized/displayed Dever values remain unchanged.
|
||||
Reference in new issue
Block a user