torch-deepaudioembedding 0.1.0__tar.gz

torch_deepaudioembedding-0.1.0/.agents/skills/audio-model-onboarding/SKILL.md

@@ -0,0 +1,323 @@
+---
+name: audio-model-onboarding
+description: Analyze, resolve, integrate, verify, card, and profile PyTorch audio model integrations according to project_spec.md.
+---
+
+# audio-model-onboarding
+
+This is the canonical, agent-neutral onboarding skill for `torch-dae`. Treat `project_spec.md` as
+normative. Preserve it unless the user explicitly asks to edit the spec.
+
+Codex and Claude entry points must resolve to this same directory. Do not create agent-specific
+scientific workflows. Keep model runtime dependencies out of the root environment. Execute only the
+workflow mode explicitly requested by the user, and never create a Git commit.
+
+Before using any mode, read the relevant references:
+
+- `references/workflow-overview.md`
+- `references/evidence-policy.md`
+- `references/repository-analysis.md`
+- `references/environment-resolution.md`
+- `references/source-strategy.md`
+- `references/checkpoint-discovery.md`
+- `references/architecture-and-embeddings.md`
+- `references/integration-planning.md`
+- `references/runtime-verification.md`
+- `references/model-card-authoring.md`
+- `references/lifecycle-and-decision-gates.md`
+- `references/failure-classification.md`
+- `references/synthetic-evaluation.md`
+
+Canonical request and response formats are available at:
+
+- `templates/agent-request.md`
+- `templates/agent-response.md`
+
+Use deterministic utilities under `scripts/` for evidence collection. They may collect, normalize,
+and validate static evidence; they do not replace scientific or architectural reasoning.
+
+## Evidence Vocabulary
+
+Every material claim must be classified as one of:
+
+- `verified_upstream_fact`
+- `locally_observed_behavior`
+- `reasoned_inference`
+- `user_provided_decision`
+- `unresolved_ambiguity`
+- `unsupported_claim`
+
+Evidence items must identify their source kind:
+
+- `source_file`
+- `source_line_or_symbol`
+- `package_metadata`
+- `configuration_file`
+- `official_documentation`
+- `paper`
+- `runtime_observation`
+- `agent_inference`
+- `user_decision`
+
+Inferences require a rationale. A verified or observed claim must not cite agent inference as proof.
+Absent evidence becomes an open question, not a fabricated value.
+
+## `analyze` Mode
+
+Purpose: investigate an unfamiliar upstream project and produce a structured technical analysis
+report plus a Markdown rendering.
+
+Required inputs: official repository URL, local repository checkout, or official package identifier.
+
+Optional inputs: paper/documentation references, candidate checkpoint URL, requested variant,
+requested checkpoint, intended task, target use, intended embedding, target platform.
+
+Prerequisites: repository baseline gates must pass; no production model card or wrapper may exist
+for the target; root dependencies must remain model-agnostic.
+
+Ordered procedure:
+
+1. Establish repository identity, revision, license, package, release, maintenance, and official
+   status evidence.
+2. Run static inventory utilities: repository, packaging, dependencies, checkpoint candidates, model
+   candidates, and output candidates.
+3. Read upstream source, docs, papers, and package metadata needed to interpret the static evidence.
+4. Produce the machine-readable report using `templates/technical-analysis-report.json`.
+5. Render the human report with `templates/technical-analysis-report.md`.
+6. Present unresolved scientific choices before making user-dependent decisions.
+
+Evidence requirements: every architecture, preprocessing, output, embedding, checkpoint,
+dependency, and source-strategy claim must cite evidence or be marked unresolved.
+
+Generated outputs: technical analysis report JSON, Markdown report, open-question list, candidate
+source strategy list, checkpoint candidates, environment evidence summary.
+
+User-decision gates: ambiguous model variant, card scope, source implementation, official
+checkpoint, preprocessing, outputs, embedding selection, technical access/authentication blocker,
+license metadata issue, distribution/publication decision, or non-equivalent wrapper behavior.
+
+Failure conditions: unsupported upstream, missing authoritative source, insufficient evidence,
+path-unsafe local checkout, attempted repository-code execution, public-network dependence in tests,
+or fabricated scientific facts.
+
+Prohibited behavior: generate a model card from unsupported fields, download checkpoints, import
+upstream code in the root environment, execute `setup.py`, or select an ambiguous embedding silently.
+
+Completion criteria: strict report validation passes, Markdown report is consistent with the JSON,
+all unresolved items are explicit, and the user has seen decision gates.
+
+Next allowed lifecycle transition: `analyzed` after report review and card authoring; otherwise
+continue in `analyze` or `resolve-environment`.
+
+## `resolve-environment` Mode
+
+Purpose: determine an evidence-supported, reproducible compatibility configuration.
+
+Required inputs: accepted analysis report and selected source/checkpoint strategy.
+
+Optional inputs: target OS/architecture, manually supplied constraints, selected candidate ID,
+controlled trial results.
+
+Prerequisites: analyze-mode evidence is sufficient; user decisions affecting compatibility are
+resolved; environment contracts and CLI are available.
+
+Ordered procedure:
+
+1. Collect Python, PyTorch, TorchAudio, NumPy, build backend, source revision, CI, Docker, and import
+   evidence.
+2. Generate ordered candidates using `scripts/generate_environment_candidates.py`.
+3. Trial only an explicitly selected evidence-motivated candidate in an isolated model-specific
+   environment.
+4. Classify every failure with `references/failure-classification.md`.
+5. On success, prepare `environments/<card-id>/environment.json`, `pyproject.toml`, `uv.lock`,
+   `sources.json`, and `verify_environment.py` using the committed environment contracts and
+   commands.
+
+Evidence requirements: candidate rationale, expected compatibility evidence, trial status, failure
+classification, diagnostics, unresolved risk, platform evidence, and exact commands.
+
+Generated outputs: environment-resolution report JSON, environment artifact draft paths, selected
+candidate record, and failed-candidate diagnostics.
+
+User-decision gates: multiple source strategies, multiple meaningful compatibility tracks,
+unsupported platform, technical access/authentication blocker, license metadata issue, or
+insufficient evidence.
+
+Failure conditions: all evidence-supported candidates exhausted, external blocker, unsupported
+implementation, source build failure, missing wheels, incompatible checkpoint, or unsafe execution.
+
+Prohibited behavior: arbitrary Cartesian version search, hidden environment materialization, adding
+model dependencies to the root environment, or duplicating the environment subsystem.
+
+Completion criteria: selected candidate is verified through environment recreation and
+verification, the lockfile is synchronized, the source manifest is coherent, and artifact
+references agree.
+
+Next allowed lifecycle transition: `environment_resolved`.
+
+## `integrate` Mode
+
+Purpose: implement the project-side wrapper while preserving upstream semantics.
+
+Required inputs: analyzed report, resolved source strategy, resolved checkpoint strategy, selected
+variant, selected embedding default when required.
+
+Optional inputs: user target use, wrapper package path, adaptation notes.
+
+Prerequisites: the user explicitly requested `MODE: integrate`; analysis is complete and reviewed;
+the source strategy, target model variant, target checkpoint, and model-specific environment
+strategy are resolved; the primary embedding is resolved or explicitly deferred by user decision;
+and the user explicitly authorized production integration.
+
+Ordered procedure:
+
+1. Define wrapper package path, model construction, checkpoint loading, preprocessing ownership,
+   sample-rate/channel/length behavior, output mapping, embedding interface, device behavior,
+   deterministic behavior, and tests.
+2. Verify source-strategy rules in `references/source-strategy.md`.
+3. Preserve upstream inference semantics and document any deviation.
+4. Add the wrapper, model-specific package code, committed environment and checkpoint
+   specifications, integration documentation, and tests needed for the selected model.
+
+Evidence requirements: source provenance, upstream forward semantics, preprocessing evidence,
+checkpoint compatibility evidence, selected embedding evidence, and user decisions.
+
+Generated outputs: integration plan, wrapper and package code, committed specifications,
+documentation, and tests for the selected model.
+
+User-decision gates: non-equivalent wrapper behavior, multiple plausible embeddings, ambiguous
+preprocessing, unclear output semantics, or vendored adaptation scope.
+
+Failure conditions: source strategy unsupported, equivalence cannot be justified, required evidence
+missing, integration prerequisites unresolved, or production integration not explicitly authorized.
+
+Prohibited behavior: adding model dependencies to the root project, committing checkpoint binaries,
+silently beginning verification or another workflow mode, creating a Git commit, semantic
+reimplementation without provenance, or presenting logits/task decisions as embeddings.
+
+Completion criteria: integration plan is reviewable, evidence-backed, and declares verification
+requirements.
+
+Next allowed lifecycle transition: none. `integrate` is a workflow mode, not a lifecycle state.
+Existing committed lifecycle states remain authoritative.
+
+## `verify` Mode
+
+Purpose: verify runtime behavior after environment resolution and wrapper implementation.
+
+Required inputs: model card draft, wrapper implementation, resolved environment, checkpoint
+specification, expected outputs and embeddings.
+
+Optional inputs: accelerator targets, extra input cases, user target assertions.
+
+Prerequisites: environment verified, wrapper exists, the selected model and checkpoint are explicit,
+and card-declared outputs and embeddings are evidence-backed.
+
+Ordered procedure:
+
+1. Test random initialization when supported, checkpoint initialization, invalid checkpoint behavior,
+   model variant agreement, and loading diagnostics.
+2. Test canonical `[B,C,T]` waveform inputs, sample-rate behavior, channels, valid lengths, short and
+   long inputs, zero input, batches, and deterministic synthetic waveforms.
+3. Observe every declared output and embedding for key, rank, shape, dtype, device, temporal
+   semantics, NaN/Inf, and repeated-call behavior.
+4. Generate a structured verification report.
+
+Evidence requirements: environment fingerprint, checkpoint hash, source revision, package identity,
+test inputs, observed outputs, embedding observations, warnings, failures, unsupported capabilities.
+
+Generated outputs: verification plan and verification report JSON.
+
+User-decision gates: unsupported capabilities, output/card mismatch, embedding/card mismatch,
+unsupported device behavior, or non-reproducible runtime observations.
+
+Failure conditions: required runtime tests fail, card/report disagree, checkpoint cannot load,
+outputs/embeddings are missing, or environment is not verified.
+
+Prohibited behavior: acquiring any checkpoint other than the explicitly selected checkpoint,
+acquiring checkpoints outside the checkpoint subsystem, running the model outside its isolated
+environment, lifecycle promotion from schema validity alone, profiling, or fabricated runtime
+observations.
+
+Completion criteria: every card-declared output and embedding is observed and the report validates.
+
+Next allowed lifecycle transition: `runtime_verified` only after `checkpoint_verified` and runtime
+verification prerequisites are satisfied.
+
+## `card` Mode
+
+Purpose: generate or update a checkpoint-specific model card from verified evidence.
+
+Required inputs: analysis report, user decisions, source/checkpoint strategy, environment artifacts,
+wrapper evidence where applicable, verification report where applicable.
+
+Optional inputs: unresolved issue decisions, intended default embedding, accepted limitations.
+
+Prerequisites: actual committed lifecycle model is checked; every populated field has traceable
+evidence; unresolved information remains explicit.
+
+Ordered procedure:
+
+1. Map report fields to the committed `ModelCard` schema.
+2. Use null, unresolved status, or issues where evidence is absent.
+3. Enforce checkpoint-specific scope: one family, one variant, one checkpoint.
+4. Validate through Pydantic and generated JSON Schema.
+5. Check lifecycle gates and card/report agreement.
+
+Evidence requirements: upstream source, paper/docs, environment evidence, checkpoint evidence,
+runtime observation, or explicit user decision for every populated field.
+
+Generated outputs: model-card JSON draft, evidence references, checkpoint specification, embedding
+specification, environment references, known issues.
+
+User-decision gates: checkpoint scope, default embedding, unresolved technical
+access/authentication blocker, license metadata issue, distribution/publication decision, source
+strategy, lifecycle promotion, or accepted known issue.
+
+Failure conditions: evidence reference missing, lifecycle skip, unsupported fact promoted, schema
+failure, card not checkpoint-specific, or report/card disagreement.
+
+Prohibited behavior: optional filler values, family-level cards for incompatible checkpoints, hidden
+lifecycle promotion, or legal conclusions from license metadata.
+
+Completion criteria: Pydantic and JSON Schema validation both pass and lifecycle gates are truthful.
+
+Next allowed lifecycle transition: the next legal committed lifecycle state only; do not invent
+states beyond `project_spec.md`.
+
+## `profile` Mode
+
+Purpose: reserved future mode that may inspect eligibility for profiling.
+
+Required inputs: runtime-verified card and verification report.
+
+Optional inputs: future profiling target platform and protocol.
+
+Prerequisites: none because no profiling workflow has been implemented.
+
+Ordered procedure:
+
+1. Refuse profiling execution.
+2. List missing prerequisites when asked.
+3. Explain expected future inputs without producing profiling evidence.
+
+Evidence requirements: runtime verification status may be inspected; no profiling measurement is
+created.
+
+Generated outputs: eligibility notes only.
+
+User-decision gates: future profiling protocol selection remains unresolved.
+
+Failure conditions: any attempt to measure latency, memory, energy, MACs, FLOPs, or benchmark
+performance.
+
+Prohibited behavior: latency measurement, memory profiling, energy measurement, MAC/FLOP
+calculation, computational characterization, benchmark reports, or lifecycle promotion to
+`profiled`.
+
+Completion criteria: profiling remains reserved and no fabricated profiling evidence exists.
+
+Next allowed lifecycle transition: none.
+
+Profiling remains unavailable until a model is runtime_verified and a profiling workflow is
+explicitly implemented and invoked.

torch_deepaudioembedding-0.1.0/.agents/skills/audio-model-onboarding/references/README.md

@@ -0,0 +1,4 @@
+# References
+
+Focused onboarding guidance lives in this directory. `SKILL.md` links each required reference and
+remains the canonical orchestration entry point.

torch_deepaudioembedding-0.1.0/.agents/skills/audio-model-onboarding/references/architecture-and-embeddings.md

@@ -0,0 +1,13 @@
+# Architecture And Embeddings
+
+Cover model classes, topology, frontend, temporal/spatial processing, backbone, heads,
+normalization, activations, pooling, sequence handling, candidate outputs, candidate embeddings, and
+variant differences.
+
+Embedding candidates must distinguish architectural intermediate tensors, pooled representations,
+task-head inputs, pre-logit representations, post-activation outputs, sequence-level embeddings,
+frame-level embeddings, and latent codes.
+
+Declare an embedding only when origin, shape semantics, batch/time dimensions, and extraction
+behavior are known. Ambiguous embeddings require a user decision. Classifier logits and task
+decisions are not embeddings.

torch_deepaudioembedding-0.1.0/.agents/skills/audio-model-onboarding/references/checkpoint-discovery.md

@@ -0,0 +1,21 @@
+# Checkpoint Discovery
+
+Collect checkpoint URLs, release assets, Hugging Face references, helper download functions, package
+resources, local paths, hashes, filenames, archive behavior, authentication needs, licenses, and
+variant mappings.
+
+Never download a real checkpoint during static analysis or synthetic evaluation. Hidden helper
+functions should be identified as evidence, but the helper must not be executed in the root
+environment. Controlled acquisition is allowed only in `verify` mode through the checkpoint
+subsystem for the explicitly selected model and checkpoint.
+
+Checkpoint candidates derived from helpers preserve `helper_symbol`, `expression_status`,
+`unresolved_components`, source file, complete URL, filename, and hash evidence. Literal URLs may
+leave helper fields unset, but helper-derived URLs must remain tied to the observed helper function
+for grounded evaluation. Hashes are associated with a candidate only when the static AST relationship
+ties the hash to that helper or checkpoint metadata structure. Repository-global or unrelated-helper
+hashes cannot satisfy a candidate. When association is unresolved, the observed hash collection is
+empty, `hash association` remains unresolved, and reports must omit the hash.
+
+Checkpoint candidates are not verified until acquired, hashed, and loaded in the intended model
+environment during a later lifecycle stage.

torch_deepaudioembedding-0.1.0/.agents/skills/audio-model-onboarding/references/environment-resolution.md

@@ -0,0 +1,29 @@
+# Environment Resolution
+
+Environment resolution is evidence-driven. Candidate versions must come from Python constraints,
+declared dependencies, lock files, setup files, CI/Docker evidence, imported APIs, release dates,
+official compatibility matrices, issue evidence when inspected, and controlled local trial results.
+Conda declarations preserve ranges such as `numpy<1.24`, exact Conda assignments such as
+`python=3.10`, and build-suffixed declarations such as `pytorch=1.13.1=<build>` without treating the
+build string as the version. GitHub Actions CI matrices may contribute exact dependency records from
+scalar, inline-list, or block-list matrix values, with `.github/workflows/ci.yml` preserved as the
+evidence path. Only values inside static `strategy` → `matrix` definitions create dependency
+records. GitHub Actions `${{ ... }}` references in setup actions, environment variables, or commands
+are ignored. Invalid declarations remain available as diagnostics but do not affect version
+selection, constraint merging, conflicts, unpinned classification, or principal dependencies.
+
+Use `generate_environment_candidates.py` to produce ordered unverified candidates. Do not run an
+arbitrary Cartesian search. Trial only explicitly selected candidates and use the environment APIs
+and CLI to materialize or verify isolated model-specific environments.
+
+Successful resolution may prepare `environments/<card-id>/environment.json`, `pyproject.toml`,
+`uv.lock`, `sources.json`, and `verify_environment.py`.
+Official-package resolution requires exact `source_package_name` and `source_package_version`
+evidence that matches the selected candidate. Accepted identity provenance is verified upstream
+`package_metadata` or locally observed `environments/<card-id>/pyproject.toml`, `uv.lock`, or
+`environment.json`; `sources.json`, `verify_environment.py`, arbitrary files, inference, and runtime
+observations cannot prove package identity. Remaining
+source-strategy decision gates block `environment_resolved`; resolved choices belong in decision
+records. Diagnostic references use `.torch-dae`-relative
+`reports/environments/<card-id>/<fingerprint>/<report>.json`, while committed verification reports
+use `verification_reports/<card-id>/<report>.json`.

torch_deepaudioembedding-0.1.0/.agents/skills/audio-model-onboarding/references/evidence-policy.md

@@ -0,0 +1,11 @@
+# Evidence Policy
+
+Classify every material claim as `verified_upstream_fact`, `locally_observed_behavior`,
+`reasoned_inference`, `user_provided_decision`, `unresolved_ambiguity`, or `unsupported_claim`.
+
+Verified facts require authoritative upstream evidence. Local observations require an inspected file,
+static utility output, or later controlled runtime report. Inferences require a rationale and must not
+be used as proof for verified or observed claims. User decisions must be recorded explicitly.
+
+When evidence is absent, leave the field unresolved or create an open question. Do not invent papers,
+datasets, metrics, model variants, preprocessing, output semantics, dependencies, hashes, or licenses.

torch_deepaudioembedding-0.1.0/.agents/skills/audio-model-onboarding/references/failure-classification.md

@@ -0,0 +1,14 @@
+# Failure Classification
+
+Resolve-environment failures must be classified with a specific cause, including:
+`python_constraint`, `dependency_conflict`, `resolution_failure`, `removed_api`, `deprecated_api`,
+`binary_or_abi_incompatibility`, `missing_binary_wheel`, `torch_torchaudio_mismatch`,
+`numpy_compatibility`, `checkpoint_incompatibility`, `source_build_failure`, `import_failure`,
+`runtime_failure`, `platform_incompatibility`, `access_or_authentication_blocker`, and
+`insufficient_evidence`.
+
+The next candidate must be motivated by evidence or failure diagnostics.
+
+Licenses are informational and non-blocking. Missing, ambiguous, or restrictive license text must be
+recorded as evidence or an open question, but it must not automatically classify a model as
+unsupported.

torch_deepaudioembedding-0.1.0/.agents/skills/audio-model-onboarding/references/integration-planning.md

@@ -0,0 +1,12 @@
+# Integration Planning
+
+The integration plan must specify wrapper path, source strategy, checkpoint strategy, construction,
+random and checkpoint initialization, preprocessing ownership, sample-rate behavior, channel
+behavior, waveform scaling, padding/truncation, valid lengths, forward signature, output
+normalization, task capabilities, embeddings, device movement, evaluation mode, deterministic
+behavior, tests, and errors.
+
+Production integration is permitted only in an explicitly requested `integrate` mode after analysis
+review, source/variant/checkpoint/embedding decisions, environment strategy resolution, and explicit
+user authorization. Integration must remain scoped to the selected model and must not start
+verification, add root model dependencies, commit checkpoints, or create a Git commit.

torch_deepaudioembedding-0.1.0/.agents/skills/audio-model-onboarding/references/lifecycle-and-decision-gates.md

@@ -0,0 +1,11 @@
+# Lifecycle And Decision Gates
+
+Use the committed lifecycle states from `project_spec.md`: `draft`, `analyzed`,
+`environment_resolved`, `checkpoint_verified`, `runtime_verified`, and `profiled`.
+
+Decision gates are required when multiple scientifically meaningful alternatives remain: card scope,
+variant, checkpoint, source implementation, source strategy, embedding, preprocessing, output
+semantics, technical access/authentication blockers, license metadata issues,
+distribution/publication decisions, or wrapper equivalence.
+
+Do not ask for decisions that objective evidence can resolve.

torch_deepaudioembedding-0.1.0/.agents/skills/audio-model-onboarding/references/model-card-authoring.md

@@ -0,0 +1,8 @@
+# Model Card Authoring
+
+Cards are checkpoint-specific: one model family, one variant, one checkpoint. Every populated field
+must trace to upstream source, paper or official docs, environment evidence, checkpoint evidence,
+runtime observation, or explicit user decision.
+
+Use nulls, unresolved states, TODO markers where allowed, and explicit issues when evidence is
+absent. Validate committed cards through both Pydantic and generated JSON Schema.

torch_deepaudioembedding-0.1.0/.agents/skills/audio-model-onboarding/references/repository-analysis.md

@@ -0,0 +1,16 @@
+# Repository Analysis
+
+Analyze repository identity, owner/name, inspected revision, license, package metadata, release/tag
+evidence, maintenance evidence, and official versus third-party status.
+
+Use static utilities first:
+
+- `inspect_repository.py`
+- `inspect_python_project.py`
+- `inspect_dependencies.py`
+- `inspect_model_candidates.py`
+- `inspect_output_candidates.py`
+- `inspect_checkpoints.py`
+
+Static candidates remain candidates until source reading or runtime evidence confirms their meaning.
+Do not execute `setup.py`, notebooks, shell scripts, or upstream imports in the root environment.

torch_deepaudioembedding-0.1.0/.agents/skills/audio-model-onboarding/references/runtime-verification.md

@@ -0,0 +1,11 @@
+# Runtime Verification
+
+Verification covers construction, checkpoint loading, invalid checkpoint behavior, model variant
+agreement, inputs, outputs, embeddings, device movement, dtypes, NaN/Inf checks, and repeated-call
+behavior.
+
+The structured report must include environment fingerprint, checkpoint hash, source revision,
+package identity, test inputs, observed outputs, embedding observations, warnings, failures,
+unsupported capabilities, and runtime evidence.
+
+Schema validity alone is insufficient for `runtime_verified`.

torch_deepaudioembedding-0.1.0/.agents/skills/audio-model-onboarding/references/source-strategy.md

@@ -0,0 +1,14 @@
+# Source Strategy
+
+Priority order:
+
+1. Official package: official, exact version lockable, required API exposed, behavior equivalent, and
+   no uncontrolled runtime download.
+2. Pinned official Git repository: official repo, immutable revision, reproducible build, required API
+   importable without modification.
+3. Minimal vendored adaptation: package/Git insufficient, copied files minimal, provenance explicit,
+   revision pinned, changes documented, semantics preserved, tests cover copied files.
+4. External PyTorch implementation: only when official upstream is not PyTorch and equivalence can be
+   justified; request a user decision when uncertain.
+
+Unsupported or non-equivalent implementations must terminate truthfully.

torch_deepaudioembedding-0.1.0/.agents/skills/audio-model-onboarding/references/synthetic-evaluation.md

@@ -0,0 +1,9 @@
+# Synthetic Evaluation
+
+Synthetic evaluation uses only self-contained repositories. Each synthetic fixture must state that
+it is scientifically meaningless and must not hide integration work.
+
+The deterministic harness validates structured workflow properties: required sections, evidence
+references, unsupported-claim rejection, decision gates, source strategy, failure classification,
+artifact validation, lifecycle constraints, canonical skill resolution, and fixture-specific expected
+outcomes.

torch_deepaudioembedding-0.1.0/.agents/skills/audio-model-onboarding/references/workflow-overview.md

@@ -0,0 +1,15 @@
+# Workflow Overview
+
+The skill converts unfamiliar upstream evidence into a structured onboarding package. The workflow is:
+upstream identifier or local checkout -> static repository inspection -> evidence collection ->
+technical analysis report -> user decision gates -> compatibility candidates -> integration plan ->
+verification plan -> model-card draft preparation.
+
+Static analysis does not execute upstream code or acquire checkpoints. Production integration and
+controlled verification are available only through explicitly requested modes after their
+prerequisites are satisfied. Static utilities gather evidence; the agent interprets architecture,
+embeddings, source strategy, and scientific ambiguity.
+
+The allowed modes are `analyze`, `resolve-environment`, `integrate`, `verify`, `card`, and
+`profile`. `profile` is reserved until a runtime-verified model and an explicitly implemented
+profiling workflow exist.

torch_deepaudioembedding-0.1.0/.agents/skills/audio-model-onboarding/scripts/README.md

@@ -0,0 +1,4 @@
+# Scripts
+
+Skill-local deterministic utilities live here. They accept explicit arguments, support `--json`, and
+perform static inspection without executing upstream repository code.

torch_deepaudioembedding-0.1.0/.agents/skills/audio-model-onboarding/scripts/common.py

@@ -0,0 +1,55 @@
+"""Shared CLI helpers for onboarding workflow skill-local scripts."""
+
+from __future__ import annotations
+
+import argparse
+import json
+import sys
+from collections.abc import Callable
+from pathlib import Path
+from typing import Any
+
+from pydantic import ValidationError
+
+from torch_dae.onboarding.inspection import OnboardingInspectionError
+
+
+def emit_json(payload: Any) -> None:
+    """Emit deterministic JSON."""
+
+    print(json.dumps(payload, indent=2, sort_keys=True, default=str))
+
+
+def repository_argument(parser: argparse.ArgumentParser) -> None:
+    """Add the standard repository argument."""
+
+    parser.add_argument("repository", type=Path, help="local repository checkout to inspect")
+    parser.add_argument("--json", action="store_true", help="emit machine-readable JSON")
+
+
+def run_json_command(
+    func: Callable[[argparse.Namespace], Any], parser: argparse.ArgumentParser
+) -> int:
+    """Run a script command with typed, traceback-free expected failures."""
+
+    args = parser.parse_args()
+    try:
+        payload = func(args)
+    except (OnboardingInspectionError, ValidationError, ValueError) as exc:
+        print(f"error: {exc}", file=sys.stderr)
+        return 2
+    if getattr(args, "json", False):
+        emit_json(payload)
+    else:
+        print(_summary(payload))
+    return 0
+
+
+def _summary(payload: Any) -> str:
+    if isinstance(payload, dict):
+        if "candidates" in payload and isinstance(payload["candidates"], list):
+            return f"{len(payload['candidates'])} candidates"
+        if "files" in payload and isinstance(payload["files"], list):
+            return f"{len(payload['files'])} files"
+        return ", ".join(sorted(payload.keys()))
+    return str(payload)

torch_deepaudioembedding-0.1.0/.agents/skills/audio-model-onboarding/scripts/generate_environment_candidates.py

@@ -0,0 +1,39 @@
+"""Generate ordered, evidence-motivated environment candidates without trial execution."""
+
+from __future__ import annotations
+
+import argparse
+from pathlib import Path
+
+from common import repository_argument, run_json_command
+
+from torch_dae.onboarding.contracts import EnvironmentCandidateGenerationResult
+from torch_dae.onboarding.inspection import generate_environment_candidates
+
+
+def command(args: argparse.Namespace) -> dict[str, object]:
+    """Generate unverified compatibility candidates."""
+
+    target_platform = args.target_platform
+    result = generate_environment_candidates(
+        args.repository,
+        target_platform=target_platform,
+        external_pytorch_root=args.external_pytorch_root,
+    )
+    return EnvironmentCandidateGenerationResult.model_validate(result).model_dump(mode="json")
+
+
+def main() -> int:
+    parser = argparse.ArgumentParser(description=__doc__)
+    repository_argument(parser)
+    parser.add_argument("--target-platform", help="optional target platform evidence")
+    parser.add_argument(
+        "--external-pytorch-root",
+        type=Path,
+        help="explicit inspected external PyTorch implementation repository root",
+    )
+    return run_json_command(command, parser)
+
+
+if __name__ == "__main__":
+    raise SystemExit(main())

torch_deepaudioembedding-0.1.0/.agents/skills/audio-model-onboarding/scripts/inspect_checkpoints.py

@@ -0,0 +1,25 @@
+"""Inspect checkpoint-like files, URLs, hashes, and helper functions."""
+
+from __future__ import annotations
+
+import argparse
+
+from common import repository_argument, run_json_command
+
+from torch_dae.onboarding.inspection import inspect_checkpoints
+
+
+def command(args: argparse.Namespace) -> dict[str, object]:
+    """Run checkpoint discovery."""
+
+    return inspect_checkpoints(args.repository)
+
+
+def main() -> int:
+    parser = argparse.ArgumentParser(description=__doc__)
+    repository_argument(parser)
+    return run_json_command(command, parser)
+
+
+if __name__ == "__main__":
+    raise SystemExit(main())