Foundry: prepare and continue a data task

The ordinary TianGong Foundry entry is foundry-tidas-import. It orchestrates external package imports and source-evidence development. Use foundry-tidas-authoring on demand for a concrete semantic work item. Foundry owns conversion, validation and execution; the skill selects inputs, interprets evidence and submits semantic decisions.

1. Prepare a separate directory

The verified combination is Foundry 0.1.7, CLI 0.1.13, Node 24.19.0 and TIDAS 0.3.0, distributed by the complete entry at Skills 0a33db1. Select foundry-tidas-import from tiangong-lca/skills through your client’s Skills installer. If Node/pnpm/Git are already available and you use the command-line installer:

pnpm dlx skills@1.5.23 add tiangong-lca/skills --skill foundry-tidas-import --agent codex --copy --yes

After installation, check skills.foundry-tidas-import.computedHash in the project’s skills-lock.json against the value below. This is the reviewed installation fingerprint, not a signature. The repository can advance; if the value differs or is missing, stop before running the bootstrap and review the new source, complete lock and qualification evidence. Never edit the hash to make the check pass.

{
  "computedHash": "b101356d3804455e4a71d34c71d693891399f529c518c27064611a726252a603"
}

For OpenClaw, replace --agent codex with --agent openclaw. Those tools belong to this command-line installation method; once the complete skill is installed, the managed Foundry runtime prepares its own components.

You need a complete installed foundry-tidas-import directory containing the original POSIX/PowerShell bootstrap and its adjacent trusted bootstrap-lock.json. Obtain them together from the same qualified distribution. Do not assemble a replacement lock from task files or temporary download URLs. Repair installation first if the lock is missing or verification fails.

This managed runtime needs no global Node, pnpm or Git. It supports Linux x64/ARM64 with glibc, macOS Apple Silicon and Windows x64. macOS Intel, Windows ARM64 and Linux musl are unsupported. The first launch downloads locked components; later launches reuse verified cache entries. A cache hit proves neither sign-in nor task completion.

Choose a writable user workspace; installed skill/runtime directories may be read-only. Save your valid input package as inputs/package.zip. This is your original input, not synthetic data generated by this tutorial. For native formats and a local conversion example, see your first tidas package.

2. Save the task specification

Save task-start.json at the workspace root:

{
  "schema": "tiangong-foundry.task-start.v1",
  "request_id": "first-foundry-package",
  "actor_id": "local-preparation",
  "lane": "external-dataset-curated-import",
  "profile_id": "generic",
  "target_entities": [
    "process"
  ],
  "sources": [
    {
      "path": "inputs/package.zip"
    }
  ],
  "seed": null,
  "account_intent": null,
  "preparation": null
}

This example prepares local candidates only. account_intent: null selects no remote account. Before account-sensitive work, use the trusted CLI OAuth flow to establish the intended project/user and select that account in the start specification. Do not guess an identity or treat sign-in as write authorization.

Source-evidence work uses lane source-evidence-dataset-development with an evidence-backed candidate JSON seed. The seed must also appear in sources. A paper or handoff document is not already a set of valid TIDAS rows.

3. Start and inspect

Replace path placeholders with actual locations. On POSIX:

sh "<skill-dir>/scripts/tiangong-runtime-bootstrap.sh" workspace init --workspace "<workspace>" --json

On Windows, use the qualified PowerShell 7 without an execution-policy bypass:

pwsh -NoProfile -File "<skill-dir>/scripts/tiangong-runtime-bootstrap.ps1" workspace init --workspace "<workspace>" --json

For subsequent calls, keep the same bootstrap prefix and append these public arguments in order. The spec path resolves against the explicit workspace. Foundry returns the task ID.

doctor --workspace <workspace> --json
task start --workspace <workspace> --spec task-start.json --json
task status --workspace <workspace> --task <returned-task-id> --actor local-preparation --json
task resume --workspace <workspace> --task <returned-task-id> --actor local-preparation --json

Check each exit code immediately: echo $? on POSIX or $LASTEXITCODE in PowerShell. Read JSON fields status, blockers, permissions, artifacts and next_actions. An exit code or empty output alone cannot establish success. Preserve the exact executable, argv and cwd of a current command action.

4. Continue from the current stage

• ready / running: follow the current action. One resume advances one registered stage; repeating an unchanged call does not resolve a blocker.
• needs_input: read the current work item, full context and template, then submit a decision or patch. Foundry validates, applies and reassesses it. Preserve the source language and add evidence-backed English for required multilingual fields.
• needs_auth: trusted CLI OAuth or explicit account selection is required. The local example stops here; do not claim a completed import.
• permissions.state: required: check the exact task, input, account and actions. Reuse valid existing approval; obtain any missing authority for the current scope.
• blocked / failed: preserve the error and evidence, resolve its stated cause, then continue the original task.
• completed: check completion/readback evidence for the current requested scope. A finished substage is not a completed task.

Changing selected input or account intent through a reviewed task-start spec creates a revision with retained history; it never resets an old attempt. After an uncertain write response, use the original task's readback/recovery action. Do not retry the mutation directly, clear records or create another directory to bypass them.

Local preparation is verified when you can identify the original input, current task ID, actual stage artifacts and a concrete next action or blocker. Full import still requires subsequent semantic work, account checks, authorization and independent readback. See organize tasks safely.

5. Updates, migration and read-only rollback

For task_runtime_changed, preserve the old workspace and first inspect it with workspace migrate --workspace <workspace> --dry-run --json. Migration requires explicit source, destination, actor, request and input selection, followed by review of the plan, stage, adoption preview, apply and audit. Do not rewrite historical records directly.

Only known local tasks with complete evidence and no attempted write can be prepared again by the current owner. Sealed, attempted or incompletely classified history may remain owner-readback-only, producing no new executable task. Never relabel it unattempted or create another directory to replay the same scope.

Read and write compatibility are checked separately. Selecting an older read-only runtime through the trusted host/CLI manager neither undoes a remote write nor grants write access. Cache reconstruction, task migration and account sign-out are separate operations; retain the workspace, original evidence and consumed-attempt markers.

Workspace read compatibility does not guarantee that an older runtime can read a newer task; retain its records and restore the matching version when the task runtime binding differs.