ossplate 0.1.0

package/scaffold/docs/README.md

@@ -0,0 +1,21 @@
+# Documentation
+
+This docs area explains how to use `ossplate` as a real tool for validating, synchronizing, and now creating a multi-registry scaffold.
+
+## Start Here
+
+- [Customizing The Template](./customizing-the-template.md)
+- [Testing Guide](./testing.md)
+- [Phase 1 Contract](./phase-1-contract.md)
+- [Upgrade Plan](./upgrade-plan.md)
+- `ossplate validate` checks owned metadata drift
+- `ossplate sync --check` verifies the repo is already synchronized
+- `ossplate create <target>` scaffolds a clean target directory and can apply identity overrides from flags
+- `ossplate init --path <dir>` hydrates an existing directory in place and can apply identity overrides from flags
+
+## What These Docs Cover
+
+- the canonical config and command surface
+- the required rename and customization surface before first release
+- the layered testing and packaging workflow
+- the phased plan for turning this tool into a broader scaffold product

package/scaffold/docs/customizing-the-template.md

@@ -0,0 +1,144 @@
+# Customizing The Template
+
+Use this checklist after creating or cloning a scaffold managed by `ossplate`. The goal is to replace inherited identity deliberately and then use the tool to keep owned metadata in sync.
+
+## Canonical Source Of Truth
+
+`ossplate.toml` is the canonical source of truth for the shared project identity.
+
+It currently owns:
+
+- project name
+- project description
+- repository URL
+- license
+- author name/email
+- Rust crate name
+- npm package name
+- Python package name
+- CLI command name
+
+`ossplate validate` checks that the owned surfaces match this config.
+
+`ossplate sync` rewrites the owned surfaces back into alignment.
+
+## Validation Policy
+
+- Placeholder identities are allowed only when the repository is discussing the template itself.
+- Placeholder identities are not allowed in shipping metadata or package-facing docs for an adopted project.
+- Command and package naming must be chosen intentionally before release.
+- Author, repository, and license fields must be set explicitly rather than inherited accidentally.
+
+The current validator follows this policy through the Rust core rather than a standalone JS rule engine.
+
+## Required Renames
+
+Replace these defaults before reuse:
+
+| Surface | Current placeholder | Where it lives |
+| --- | --- | --- |
+| Rust crate name | `ossplate` | `core-rs/Cargo.toml` |
+| npm package name | `ossplate` | `wrapper-js/package.json` |
+| PyPI package name | `ossplate` | `wrapper-py/pyproject.toml` |
+| CLI command | `ossplate` | `ossplate.toml`, `wrapper-js/package.json`, `wrapper-py/pyproject.toml` |
+| Repository URL | `https://github.com/stefdevscore/ossplate` | Rust, npm, Python metadata |
+| Author/email | `Stef <stefdevscore@github.com>` / `stefdevscore@github.com` | Rust, npm, Python metadata |
+| Package-facing template branding | `OSS template`, `template` identity in wrapper docs | `wrapper-js/README.md`, `wrapper-py/README.md` |
+
+## Files To Review
+
+- `README.md`
+- `ossplate.toml`
+- `core-rs/Cargo.toml`
+- `wrapper-js/package.json`
+- `wrapper-js/README.md`
+- `wrapper-py/pyproject.toml`
+- `wrapper-py/README.md`
+- `.github/workflows/*.yml`
+
+## What `ossplate validate` Enforces
+
+The tool reports:
+
+- drift between `ossplate.toml` and the owned manifest fields
+- drift between `ossplate.toml` and wrapper package README identity
+- missing or malformed owned metadata in Cargo, npm, or Python surfaces
+
+The tool does not currently rewrite or own:
+
+- CI workflow logic
+- publish workflow auth logic
+- the root README body beyond the marked identity block
+- arbitrary docs prose
+
+The root `README.md` now has a bounded identity section managed by `ossplate sync`. Content outside that marker block remains intentionally manual.
+
+The workflow files now expose a similarly bounded identity surface:
+
+- `.github/workflows/ci.yml`
+- `.github/workflows/publish.yml`
+- `.github/workflows/publish-npm.yml`
+
+`sync` owns only the display name between `ossplate:workflow-name` markers. Trigger logic, jobs, auth, and shell steps remain manual.
+
+## First-Run Sequence After Cloning
+
+1. Either update `ossplate.toml` directly or use `create` / `init` with identity flags.
+2. Run `cargo run --manifest-path core-rs/Cargo.toml -- sync`.
+3. Run `cargo run --manifest-path core-rs/Cargo.toml -- validate`.
+4. Run the layered verification flow from [Testing Guide](./testing.md).
+5. Only then expand product code or publish configuration.
+
+## Create Workflow
+
+To scaffold a fresh target from the current template tree:
+
+```bash
+cargo run --manifest-path core-rs/Cargo.toml -- create ../my-new-project \
+  --name "My Project" \
+  --repository "https://github.com/acme/my-project" \
+  --author-name "Acme OSS" \
+  --author-email "oss@acme.dev" \
+  --rust-crate "my-project-core" \
+  --npm-package "@acme/my-project" \
+  --python-package "my-project-py" \
+  --command "my-project"
+```
+
+That copies the curated scaffold payload into the target directory, applies any identity overrides to `ossplate.toml`, then runs `sync` on the new target.
+
+The packaged scaffold intentionally excludes wrapper test suites and maintainer-only validation scripts. Generated projects get the delivery baseline and operator docs, not the source repo's internal test harness.
+
+## Init Workflow
+
+To hydrate an existing directory in place:
+
+```bash
+cargo run --manifest-path core-rs/Cargo.toml -- init \
+  --path ../existing-project \
+  --name "Existing Project" \
+  --command "existing-project"
+```
+
+`init` ensures the expected scaffold layout exists, copies any missing scaffold files, applies any requested identity overrides, and then runs `sync` so owned metadata matches `ossplate.toml`.
+
+## Supported Identity Flags
+
+- `--name`
+- `--description`
+- `--repository`
+- `--license`
+- `--author-name`
+- `--author-email`
+- `--rust-crate`
+- `--npm-package`
+- `--python-package`
+- `--command`
+
+## Why This Exists
+
+This tool is trying to optimize for a real delivery baseline:
+
+- CI should fail before placeholder identity reaches a release path.
+- package metadata should not be inherited by accident
+- future phases can add richer scaffold creation and maintenance without first cleaning up metadata drift

package/scaffold/docs/phase-1-contract.md

@@ -0,0 +1,52 @@
+# Phase 1 Contract
+
+Phase 1 establishes a single canonical CLI surface in the Rust core. The JavaScript and Python packages are wrappers that delegate to that binary rather than implementing separate behavior.
+
+## Canonical Commands
+
+- `version`
+  returns JSON with the tool identity and package version
+- `validate [--path <dir>] [--json]`
+  returns validation results for owned metadata surfaces
+- `sync [--path <dir>] [--check]`
+  rewrites or checks owned metadata surfaces against the canonical project identity
+- `create <target>`
+  copies the curated scaffold payload into a clean target directory, applies optional identity overrides, and synchronizes the owned metadata surfaces there
+- `init [--path <dir>]`
+  hydrates an existing directory with the expected scaffold layout, applies optional identity overrides, and then synchronizes owned metadata in place
+
+Both commands are available from source checkouts and installed wrapper artifacts that include the staged scaffold payload.
+
+## Expected Output Shapes
+
+```json
+{"tool":"ossplate","version":"0.1.0"}
+{"ok":true,"issues":[]}
+```
+
+## Wrapper Model
+
+- Rust is the source of truth for command parsing and output.
+- JavaScript and Python are adapter layers that resolve a packaged binary and forward arguments unchanged.
+- Wrappers preserve stdout, stderr, and exit status from the core binary.
+
+## Local Development Override
+
+Both wrappers support `OSSPLATE_BINARY` to bypass packaged binary lookup during local development and parity testing.
+
+`create` and `init` also honor `OSSPLATE_TEMPLATE_ROOT` when the template source needs to be overridden explicitly.
+
+## Packaged Binary Layout
+
+Wrappers expect binaries under:
+
+```text
+bin/<target>/<executable>
+```
+
+Supported target identifiers are aligned across wrappers:
+
+- `darwin-arm64`
+- `darwin-x64`
+- `linux-x64`
+- `win32-x64`

package/scaffold/docs/testing.md

@@ -0,0 +1,71 @@
+# Testing Guide
+
+`ossplate` uses layered verification so the scaffold stays usable as both a source checkout and an installed wrapper distribution.
+
+## Default Layers
+
+### Smoke
+
+- `cargo run --manifest-path core-rs/Cargo.toml -- validate`
+- `cargo run --manifest-path core-rs/Cargo.toml -- sync --check`
+- `cargo run --manifest-path core-rs/Cargo.toml -- create ../tmp-project`
+- `cargo run --manifest-path core-rs/Cargo.toml -- init --path ../tmp-project`
+
+### Unit And Integration
+
+- `cargo test`
+- `npm test`
+- `PYTHONPATH=src python3 -m unittest discover -s tests -p 'test_*.py'`
+
+These suites cover:
+
+- Rust command parsing and metadata sync behavior
+- wrapper parity against the Rust core
+- installed npm and wheel artifact smoke checks for `version`, `create`, and `validate`
+
+### Packaging
+
+- `npm pack --dry-run` in `wrapper-js/`
+- `python -m build --wheel` in `wrapper-py/`
+
+JavaScript packaging stages distribution assets through `prepack`.
+
+Python packaging stages distribution assets through the Hatch build hook in `wrapper-py/hatch_build.py`.
+
+Artifact assertions are part of the required packaging layer:
+
+- npm tarball content must include the curated scaffold files from `scaffold-manifest.json`
+- npm tarball content must exclude wrapper test files and repo-only validation scripts
+- Python wheel content must include the curated scaffold files from `scaffold-manifest.json`
+- Python wheel content must exclude wrapper test files and repo-only validation scripts
+
+## Recommended Local Order
+
+Default path:
+
+```bash
+./scripts/verify.sh
+```
+
+Underlying command order:
+
+1. `cargo fmt --check`
+2. `cargo clippy --manifest-path core-rs/Cargo.toml -- -D warnings`
+3. `cargo test`
+4. `cargo run --quiet --manifest-path core-rs/Cargo.toml -- validate --json`
+5. `cargo run --quiet --manifest-path core-rs/Cargo.toml -- sync --check`
+6. `npm test`
+7. `npm pack --dry-run`
+8. `PYTHONPATH=src python3 -m unittest discover -s tests -p 'test_*.py'`
+9. `python -m build --wheel`
+
+## CI Expectations
+
+CI currently enforces:
+
+- template readiness via `validate` and `sync --check`
+- Rust formatting, clippy, and tests
+- JS build, tests, and package dry-run
+- Python tests and wheel build
+
+The current artifact tests are the required release-confidence floor. Future phases can add broader platform coverage or slower end-to-end suites without changing the basic layered model.

package/scaffold/docs/upgrade-plan.md

@@ -0,0 +1,251 @@
+# Ossplate Upgrade Plan
+
+## Goal
+
+Turn `ossplate` from a minimal multi-registry demo into a production-ready scaffold tool with:
+
+- one canonical core program
+- real wrapper parity across Rust, TypeScript/JavaScript, and Python
+- robust CI and publish workflows with explicit auth fallbacks
+- layered testing guidance and enforcement
+- a structure that can scale toward a hexagonal architecture shell
+
+The product behavior is now real in the core maintenance and scaffold paths. Remaining work is about hardening, ergonomics, and release scale.
+
+## Operating Principles
+
+- Keep one source of truth for CLI behavior and output contracts.
+- Prefer thin wrappers over duplicated implementations.
+- Fail early when template placeholders were not replaced.
+- Use OIDC where the registry path is configured and supported, with explicit token fallbacks elsewhere.
+- Require install/build/test/package checks before any publish step.
+- Keep the starter small, but not fake in the critical paths.
+
+## Phase 0: Stabilize the Template Baseline
+
+Purpose: make the current scaffold safe to evolve and hard to misuse.
+
+### P0
+
+- Add a release-readiness validator that fails on placeholder metadata.
+- Validate package names, crate name, binary names, repository URLs, author fields, and obvious placeholder strings.
+- Add a root documentation index under `docs/` so implementation docs have a stable home.
+
+### P1
+
+- Normalize naming conventions across Cargo, npm, and PyPI packages.
+- Define the canonical command name and the expected wrapper naming pattern.
+- Document the template customization surface:
+  project name, package ids, repo URL, author, license, binary name, description.
+
+### P2
+
+- Remove or tighten weak placeholder copy in README files.
+- Add a checklist for creating a new project from the template.
+
+### Exit Criteria
+
+- A new maintainer can identify every required rename/customization step.
+- CI can fail automatically if placeholder identity leaks into a release path.
+
+## Phase 1: Establish the Canonical Core and Wrapper Parity
+
+Purpose: stop treating each ecosystem as a separate product stub.
+
+### P0
+
+- Make the Rust binary the canonical executable implementation.
+- Define a small, stable placeholder command contract:
+  `--help`, `version`, `health`, and one example command returning structured JSON.
+- Convert the JavaScript package into a real wrapper around the packaged binary.
+- Convert the Python package into a real wrapper around the packaged binary.
+- Ensure wrappers preserve exit codes, stdout, and stderr from the core binary.
+
+### P1
+
+- Move `wrapper-js` source to TypeScript and publish built JavaScript artifacts.
+- Add binary resolution logic for supported platforms in both wrappers.
+- Add wrapper tests that assert parity against the core binary output contract.
+
+### P2
+
+- Add a small shared contract document covering commands, arguments, output, and error behavior.
+- Add support for environment-based binary overrides for local development and debugging.
+
+### Exit Criteria
+
+- Rust, JS, and Python packages all exercise the same underlying behavior.
+- Wrapper packages no longer maintain separate hand-written CLI logic.
+
+## Phase 2: Production-Grade Quality Gates
+
+Purpose: make the scaffold trustworthy before publish automation runs.
+
+### P0
+
+- Expand CI to enforce core quality gates in all three environments.
+- Add Rust checks:
+  `cargo fmt --check`, `cargo clippy -- -D warnings`, `cargo test`.
+- Add JS/TS checks:
+  install, typecheck, test, package dry-run.
+- Add Python checks:
+  environment setup, tests, wheel/sdist build, install-from-built-artifact smoke test.
+- Add a cross-package parity job that verifies wrappers match core contract behavior.
+
+### P1
+
+- Add artifact-level smoke tests for packaged npm and wheel outputs.
+- Add a matrix strategy where it materially improves confidence for supported platforms.
+- Make CI logs and job names intentionally clear for template adopters.
+
+### P2
+
+- Add optional local aggregate commands or scripts for running all checks consistently.
+- Add a contributor quickstart for running the same quality gates outside CI.
+
+### Exit Criteria
+
+- A release candidate must pass formatting, linting, unit tests, packaging, and parity checks.
+- Published artifacts are verified before publish jobs run.
+
+## Phase 3: Robust Publishing with OIDC First and Concrete Fallbacks
+
+Purpose: keep publishing reliable even when registry auth or registry behavior is imperfect.
+
+### P0
+
+- Keep publish workflows rerun-safe with published-version detection before attempting release.
+- Use OIDC or trusted publishing where supported and configured.
+- For the current `ossplate` baseline:
+  PyPI uses OIDC, Cargo uses OIDC with `CARGO_TOKEN` fallback, and npm uses `NPM_TOKEN`.
+- Add explicit secret-based fallbacks:
+  `NPM_TOKEN`, PyPI API token, and `CARGO_REGISTRY_TOKEN`.
+- Make auth mode selection visible in workflow logs.
+- Preserve non-destructive handling of already-published versions.
+
+### P1
+
+- Document exact registry setup steps for both preferred and fallback auth modes.
+- Add validation that publish jobs fail clearly when neither OIDC nor token auth is configured.
+- Tighten registry-specific behavior:
+  npm public access, PyPI trusted publishing expectations, crates.io version detection and retry behavior.
+
+### P2
+
+- Add optional manual dispatch inputs for dry-run or targeted registry publish flows if they simplify maintenance.
+- Add guidance for organizations that intentionally disable OIDC and standardize on tokens.
+
+### Exit Criteria
+
+- Publish workflows are understandable, rerunnable, and resilient.
+- Auth failures are explicit and actionable rather than implicit or flaky.
+
+## Phase 4: Layered Testing Guidance and Scaffolding
+
+Purpose: teach adopters how to scale verification without overcomplicating the starter.
+
+### P0
+
+- Add docs for the default testing pyramid:
+  smoke, unit, integration/parity, and release verification.
+- Define minimum required tests for any project generated from this template.
+- Document how wrapper parity tests fit into the scaffold.
+
+### P1
+
+- Add optional docs for live end-to-end browser testing with Playwright when a generated project includes a web UI.
+- Clarify that Playwright is not a default requirement for non-UI projects.
+- Add example CI placement for smoke vs slower e2e suites.
+
+### P2
+
+- Add template examples of failure triage:
+  unit regression, packaging regression, publish regression, wrapper parity regression.
+
+### Exit Criteria
+
+- The testing strategy is clear enough that teams do not improvise incompatible structures from scratch.
+- Optional e2e guidance exists without forcing UI assumptions onto every project.
+
+## Phase 5: Architecture Shell and Scaling Docs
+
+Purpose: leave room for serious product evolution without bloating the first scaffold cut.
+
+### P1
+
+- Add architecture docs for a hexagonal baseline:
+  domain, application, adapters, and delivery surfaces.
+- Define where product logic belongs and where it should not live.
+- Document wrappers as adapters rather than alternate implementations.
+
+### P2
+
+- Add an example directory shell that future projects can expand into as complexity grows.
+- Link to the stronger internal reference material that informed this structure.
+- Add ADR guidance if the template grows beyond a small starter.
+
+### Exit Criteria
+
+- The template can scale into a maintainable project layout without major restructuring.
+- The initial starter remains small and understandable.
+
+## Recommended Execution Order
+
+1. Phase 0
+2. Phase 1
+3. Phase 2
+4. Phase 3
+5. Phase 4
+6. Phase 5
+
+Rationale:
+
+- Phase 0 prevents accidental misuse while the template is still changing.
+- Phase 1 fixes the most important structural flaw: duplicated CLI stubs.
+- Phase 2 makes the scaffold trustworthy.
+- Phase 3 hardens release automation after the package surfaces are stable.
+- Phase 4 and Phase 5 improve scale and adoption quality without blocking the core scaffold.
+
+## Suggested Near-Term Milestones
+
+### Milestone A
+
+Complete Phases 0 and 1.
+
+Outcome:
+`ossplate` becomes a real scaffold with one canonical core and thin wrappers.
+
+### Milestone B
+
+Complete Phase 2 and the P0 items in Phase 3.
+
+Outcome:
+the scaffold becomes release-grade with meaningful quality gates and robust publish behavior.
+
+### Milestone C
+
+Complete Phases 4 and 5.
+
+Outcome:
+the scaffold becomes easier to adopt, extend, and scale across future projects.
+
+## Current State
+
+Completed:
+
+- release-readiness checks are wired into CI
+- JS and Python are thin wrappers over the Rust core
+- the Rust core now provides `version`, `validate`, `sync`, `create`, and `init`
+- `ossplate.toml` is the canonical identity source for owned metadata surfaces
+- installed npm and Python artifacts now carry the staged scaffold payload for `create` and `init`
+- artifact smoke tests prove installed distributions can run `version`, `create`, and `validate`
+- scaffold payload staging is now driven by an explicit curated manifest instead of a broad repo snapshot
+- Python packaging stages distribution assets through its build hook
+- CI now enforces Rust formatting and clippy alongside the existing test/package checks
+
+## Next Steps
+
+- expand `sync` ownership carefully beyond the root README identity block and into selected workflow identity fields where safe
+- improve `validate` and `sync --check` output further if diff-style rendering becomes necessary
+- keep the root verification workflow aligned with CI as new checks are added
+- harden publish workflows with the OIDC-first fallback strategy from Phase 3

package/scaffold/ossplate.toml

@@ -0,0 +1,15 @@
+[project]
+name = "Ossplate"
+description = "A practical baseline for shipping one project across Cargo, npm, and PyPI without starting from scratch every time."
+repository = "https://github.com/stefdevscore/ossplate"
+license = "Unlicense"
+
+[author]
+name = "Stef"
+email = "stefdevscore@github.com"
+
+[packages]
+rust_crate = "ossplate"
+npm_package = "ossplate"
+python_package = "ossplate"
+command = "ossplate"

package/scaffold/scripts/verify.sh

@@ -0,0 +1,36 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+ROOT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
+
+find_python() {
+  local candidate
+  for candidate in python3.14 python3.13 python3.12 python3.11 python3.10 python3; do
+    if command -v "$candidate" >/dev/null 2>&1; then
+      if "$candidate" -c 'import sys; raise SystemExit(0 if sys.version_info >= (3, 10) else 1)' >/dev/null 2>&1; then
+        printf '%s\n' "$candidate"
+        return 0
+      fi
+    fi
+  done
+  printf 'verify.sh: no Python 3.10+ interpreter found on PATH\n' >&2
+  return 1
+}
+
+PYTHON_BIN="$(find_python)"
+
+run_step() {
+  local label="$1"
+  shift
+  printf '\n[%s]\n' "$label"
+  "$@"
+}
+
+run_step "rust:fmt" cargo fmt --check --manifest-path "$ROOT_DIR/core-rs/Cargo.toml"
+run_step "rust:clippy" cargo clippy --manifest-path "$ROOT_DIR/core-rs/Cargo.toml" -- -D warnings
+run_step "rust:test" cargo test --manifest-path "$ROOT_DIR/core-rs/Cargo.toml"
+run_step "tool:validate" cargo run --quiet --manifest-path "$ROOT_DIR/core-rs/Cargo.toml" -- validate --path "$ROOT_DIR" --json
+run_step "tool:sync-check" cargo run --quiet --manifest-path "$ROOT_DIR/core-rs/Cargo.toml" -- sync --path "$ROOT_DIR" --check
+run_step "js:test" bash -lc "cd \"$ROOT_DIR/wrapper-js\" && npm test"
+run_step "js:pack" bash -lc "cd \"$ROOT_DIR/wrapper-js\" && npm pack --dry-run"
+run_step "py:test" bash -lc "cd \"$ROOT_DIR/wrapper-py\" && PYTHONPATH=src \"$PYTHON_BIN\" -m unittest discover -s tests -p 'test_*.py'"

package/scaffold/wrapper-js/README.md

@@ -0,0 +1,7 @@
+# JavaScript Wrapper For Ossplate
+
+This package is the JavaScript wrapper surface for Ossplate.
+
+It delegates to the canonical Rust binary instead of implementing its own CLI behavior.
+
+Use `OSSPLATE_BINARY` during local development to point the wrapper at a specific binary.

package/scaffold/wrapper-js/bin/darwin-x64/ossplate

@@ -0,0 +1,3 @@
+#!/bin/sh
+
+printf '{"status":"packaged-stub"}\n'

package/scaffold/wrapper-js/bin/linux-x64/ossplate

@@ -0,0 +1,3 @@
+#!/bin/sh
+
+printf '{"status":"packaged-stub"}\n'

package/scaffold/wrapper-js/bin/ossplate.js

@@ -0,0 +1,5 @@
+#!/usr/bin/env node
+
+import { runOssplate } from "../dist/index.js";
+
+runOssplate(process.argv.slice(2));

package/scaffold/wrapper-js/bin/win32-x64/ossplate.exe

@@ -0,0 +1,3 @@
+#!/bin/sh
+
+printf '{"status":"packaged-stub"}\n'

package/scaffold/wrapper-js/package-lock.json

@@ -0,0 +1,51 @@
+{
+  "name": "ossplate",
+  "version": "0.1.0",
+  "lockfileVersion": 3,
+  "requires": true,
+  "packages": {
+    "": {
+      "name": "ossplate",
+      "version": "0.1.0",
+      "license": "Unlicense",
+      "bin": {
+        "ossplate": "bin/ossplate.js"
+      },
+      "devDependencies": {
+        "@types/node": "^24.6.0",
+        "typescript": "^5.9.3"
+      }
+    },
+    "node_modules/@types/node": {
+      "version": "24.12.0",
+      "resolved": "https://registry.npmjs.org/@types/node/-/node-24.12.0.tgz",
+      "integrity": "sha512-GYDxsZi3ChgmckRT9HPU0WEhKLP08ev/Yfcq2AstjrDASOYCSXeyjDsHg4v5t4jOj7cyDX3vmprafKlWIG9MXQ==",
+      "dev": true,
+      "license": "MIT",
+      "dependencies": {
+        "undici-types": "~7.16.0"
+      }
+    },
+    "node_modules/typescript": {
+      "version": "5.9.3",
+      "resolved": "https://registry.npmjs.org/typescript/-/typescript-5.9.3.tgz",
+      "integrity": "sha512-jl1vZzPDinLr9eUt3J/t7V6FgNEw9QjvBPdysz9KfQDD41fQrC2Y4vKQdiaUpFT4bXlb1RHhLpp8wtm6M5TgSw==",
+      "dev": true,
+      "license": "Apache-2.0",
+      "bin": {
+        "tsc": "bin/tsc",
+        "tsserver": "bin/tsserver"
+      },
+      "engines": {
+        "node": ">=14.17"
+      }
+    },
+    "node_modules/undici-types": {
+      "version": "7.16.0",
+      "resolved": "https://registry.npmjs.org/undici-types/-/undici-types-7.16.0.tgz",
+      "integrity": "sha512-Zz+aZWSj8LE6zoxD+xrjh4VfkIG8Ya6LvYkZqtUQGJPZjYl53ypCaUwWqo7eI0x66KBGeRo+mlBEkMSeSZ38Nw==",
+      "dev": true,
+      "license": "MIT"
+    }
+  }
+}