docs: document the preferred stack - #5
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7d7d86b1c0
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| Check offline behavior explicitly for products that need it. Keep exact versions | ||
| in manifests and lockfiles under the [dependency standard](dependencies.md), and |
There was a problem hiding this comment.
When contributors apply this guidance to library runtime or peer dependencies, “exact versions in manifests” directs them to exact-pin dependencies even though docs/dependencies.md explicitly permits intentional semver ranges for Node libraries and requires Rust library manifests to express the compatibility range consumers resolve. This can prevent consumers from receiving compatible updates and makes the two canonical guides disagree; limit exact pinning to tools and lockfiles, or state that manifests must follow the dependency standard’s package-specific range policy.
Useful? React with 👍 / 👎.
Change
The tooling guide explains repository commands but does not help contributors choose a stack for new work. Add our preferred web, native, desktop, and firmware tools with their intended uses and links to upstream documentation. Keep adoption driven by product needs and existing project constraints, preserve the dependency standard's manifest ranges and tool pins, and make the new section discoverable from the README.
Validation
just checkpassed all 31 tests, including local Markdown links and JSON validation.git diff --checkpassed; reviewed the documentation against existing standards and upstream references.