mait.sh1.69.2

Private beta: features and content may change. No warranty; use at your own risk.

Docs / Launcher and command-line tools

AIDC

Keep required tool versions with the project, install supported tools and inspect what your shell uses.

For developers, platform teams, and CI owners who need repeatable tools across repositories and machines.

Read from the top for the basics; the later sections go deeper.

Beta

What it doesBasics

  • Version patterns and per-project pins
  • Source-aware package verification
  • Team-wide setup from .aidc.yaml
  • Temporary and persistent version selection
  • Upgrade, prune, and diagnostic workflows

First useBasics

  1. Prepare one declared toolchain and verify the executable versions used by the project.
  2. Review upgrades deliberately and verify the project's actual task afterward.
  3. Use AIDC current and AIDC doctor to explain the active environment.

Everyday tasksEveryday use

Reproduce a team toolchain from the repository

A contributor enters a fresh workspace that needs the project’s required tool versions.

  1. Review the tool names and version patterns committed in .aidc.yaml.
  2. Run workspace setup to resolve and install missing versions from the configured sources.
  3. Initialize the supported shell integration and open or refresh the shell.
  4. Compare the active versions with the project requirements.

What you getThe workspace exposes tool versions that satisfy the same repository definition used by the rest of the team.

How to check: AIDC setup reports source-specific installation results; AIDC current reports the active value configured in the nearest manifest for each tool.

Evaluate a tool upgrade without obscuring the project pin

A maintainer wants to test a newer tool release while keeping the committed team requirement visible.

  1. Inspect available and already installed versions for the tool.
  2. Install the candidate explicitly, then use AIDC use for a session-only selection.
  3. Run the project validation workflow and compare behaviour with the currently declared version.
  4. Use AIDC set only after the team accepts the project change; otherwise exit the session or restore the previous selection.

What you getThe candidate can be evaluated deliberately without silently replacing the repository’s declared expectation.

How to check: Version listings and current-state output show the installed candidate, active selection, and project requirement separately.

Settings to decideAdvanced

Choose version precision
Use project patterns broad enough for the team’s compatibility policy and narrow enough to prevent an unreviewed major or minor transition. Exact pins provide the strongest repeatability.
Choose package-source policy
Decide whether a tool may resolve through the authenticated hub, a supported vendor source, or only one approved path. Keep verification enabled for the chosen sources.
Choose user or system data scope
Use the user data directory for ordinary workspace ownership. Use a system path only where image construction or shared administration explicitly owns it.
Select shell activation behaviour
Initialize a supported shell and verify PATH ordering so AIDC’s selected version, rather than a host or image fallback, is the executable users invoke.

CommandsAdvanced

$ aidc setup
$ aidc current
$ aidc install <tool>@<version>
$ aidc set <tool>@<version>
$ aidc doctor

Problems and fixesHelp

What you seeCheckFix
Setup cannot find a version satisfying the project requirement.Inspect the declared version pattern, active channel, available versions, platform, architecture, and package-source status.Correct an unintended pattern or source/channel selection; otherwise publish or approve a compatible package rather than silently substituting an unrelated version.
Installation stops on signature, checksum, manifest, or expected-command validation.Retain the exact failing verification stage and confirm the artifact identity and source match the requested tool, version, platform, and architecture.For Hub packages, obtain a valid signed package; Hub verification is mandatory. For vendor packages, follow the published verification policy; use the documented GPG emergency override only as an explicitly reviewed recovery exception.
A shell runs a different executable than AIDC current reports.Inspect shell initialization and command lookup order, including aliases and binaries earlier on PATH.Apply the documented shell integration, start a fresh shell, and verify both command location and reported version.
What you see
Setup cannot find a version satisfying the project requirement.
Check
Inspect the declared version pattern, active channel, available versions, platform, architecture, and package-source status.
Fix
Correct an unintended pattern or source/channel selection; otherwise publish or approve a compatible package rather than silently substituting an unrelated version.
What you see
Installation stops on signature, checksum, manifest, or expected-command validation.
Check
Retain the exact failing verification stage and confirm the artifact identity and source match the requested tool, version, platform, and architecture.
Fix
For Hub packages, obtain a valid signed package; Hub verification is mandatory. For vendor packages, follow the published verification policy; use the documented GPG emergency override only as an explicitly reviewed recovery exception.
What you see
A shell runs a different executable than AIDC current reports.
Check
Inspect shell initialization and command lookup order, including aliases and binaries earlier on PATH.
Fix
Apply the documented shell integration, start a fresh shell, and verify both command location and reported version.

All AIDC problems and fixes →

Good to knowHelp

  • AIDC manages development tools and supported apt system packages; AIDC Init and the launcher handle container identity, mounts and host provisioning.
  • Exact tool versions pinned in the project give each machine the same toolchain versions.
  • Installed tools are reused separately from aidev state and devsso credentials.