Install check, capture, write, check.
For standard tools, build checks whether the tool is installed and can ask aidc to install it. This does not establish the origin of every file in an existing installation. A completed build leaves an archive and a manifest beside it and performs local package checks. Run verify on the exact pair before sharing it.
In Docker mode the capture happens in a container; in direct mode it happens in place. Either way the check can install the tool in the current environment first. An existing installation without a verification marker is accepted with a warning.
A record that names the archive's exact contents.
The manifest sits beside the archive and describes it: the tool, version and target, the size and file count, a checksum of the archive and the commands the tool provides. verify and publish read it, and the hub signs the package when it is published. The manifest must stay paired with the exact archive it describes; copy or move the two together.
Identity, checksum, contents and expectations.
| Check | What it compares |
|---|---|
| Identity | Tool, version, platform, architecture and distribution in the manifest against the command |
| Checksum and sizes | The archive is non-empty, its checksum equals the manifest's, and the sizes and file count are consistent |
| Commands | The commands the tool should provide are present in the archive |
| Environment | The expected environment-variable names appear in the manifest |
| Hub baseline | With credentials and a published package of the same tool and target, the commands from that package are still present |
These checks do not execute the packaged tool or establish destination compatibility. Check the commands and extensions your consumers need at the destination. Individual Android component builds can fail the current checks; hold failed pairs out of publication and ask the packaging owner to confirm support.
Packages, tools and credentials are separate.
Packages are written to ./packages/<tool>/<version>/, or to the directory set by AIDC_PACK_STORAGE_PATH, with the target in each file name. Tools that aidc installed for a build stay in your aidc installation, and a build can leave some behind. Your MAIT credentials, if you have them, are kept where aidc login stored them.
The package directory and the AIDC installation are separate. Consumers usually install the published tool through AIDC. AIDC also supports configured local package storage, with its own layout and installation workflow; the builder output directory is not automatically an installation source. Ask the environment owner to prepare that path when distributing offline.
Only publishing needs them.
| Command | Credentials |
|---|---|
build, inspect, version, help, legal | Not needed |
verify | Optional; used only for the hub baseline comparison |
publish | Required, with the publish feature |
Credentials without the publish feature are rejected by the hub with a message that names the feature needed. aidc-pack presents the credentials file when it connects; it does not issue credentials or sign you in. Run aidc login on the authoring machine to store them. Keep the file readable only by the publishing account, never paste its contents into a command argument, a manifest or a support report, and remove temporary AIDC_CREDENTIALS_PATH overrides when the session ends.