Operate

Repo targets

Value-free repo requirements, target-scoped secret delivery, worked examples, and how app and MCP targets resolve inside a bound project.

HASP can keep a value-free repo contract in .hasp.manifest.json.

Read Value-free manifests first if you need the full contract. This page focuses on the commands you run after the manifest exists.

The manifest answers two questions without storing secrets:

  • what this repo needs
  • which target should receive which subset

A target is a named workflow inside a project, such as server.dev, server.integration, or release.sign. It is not authorization. Target expansion still goes through the normal project binding, grant, redaction, and audit checks.

Manifest shape

{
  "version": "v1",
  "references": [
    { "alias": "secret_01", "item": "OPENAI_API_KEY" }
  ],
  "requirements": [
    {
      "ref": "secret_01",
      "kind": "kv",
      "required": true,
      "classification": "secret"
    }
  ],
  "targets": [
    {
      "name": "server.dev",
      "root": "apps/server",
      "command": ["make", "-C", "apps/server", "test-integration"],
      "delivery": [
        { "as": "env", "name": "OPENAI_API_KEY", "ref": "secret_01" }
      ],
      "examples": [
        { "format": "env", "path": "apps/server/.env.example" }
      ]
    }
  ]
}

The file is committed. Secret values stay in the vault. Targets may also carry explicit non-secret configuration in literal_env, such as {"CI":"1"}. Those strings are committed with the manifest, so include only values you intend repo readers to see.

A target's literal_env map uses the same byte-preserving configuration channel as CLI --literal-env and MCP literal_env. Destination names cannot collide with secret delivery names and must pass the manifest's stricter env name rules. Exact literal changes, including whitespace, require renewed local review. Target runs reject additional explicit env, file, or literal maps. app connect --target snapshots the literal map with the command and references. write-env --target rejects targets with literals; use run or inject for runtime configuration. Target inspection through MCP lists literal names only. See the delivery channel table.

Inspect requirements

Use this when a teammate needs to know which local vault items to create:

hasp project requirements --project-root .
hasp project requirements --project-root . --target server.dev --json

The output reports refs, kinds, target usage, and present/exposed state. It may suggest hasp secret add commands, but it does not create items, approve access, write value files, or run target commands.

Inspect targets

hasp project targets --project-root .
hasp project doctor --project-root . --json

Target inspection omits command argv in agent-facing MCP listing. Project doctor uses a dedicated safe JSON schema with diagnostic codes, refs, kinds, classifications, and booleans only. It flags unavailable target commands, stale examples, unignored generated outputs, workspace-visible secret delivery, kind mismatches, and target drift without printing values or command argv.

Generate examples

Examples are placeholder files for framework compatibility:

hasp project examples --project-root . --target server.dev --check
hasp project examples --project-root . --target server.dev --write

Generated examples contain placeholders such as __HASP_SECRET__; they never resolve vault values. HASP writes a marker into generated examples and refuses to overwrite stale hand-authored files silently.

Run a target

hasp run --project-root . --target server.dev --grant-project window --grant-secret session
hasp inject --project-root . --target release.sign -- ./scripts/package-release.sh

run and inject reject extra --env or --file mappings when --target is used. A target does not mean "all project secrets"; it expands only the delivery entries declared for that target.

If a target has no command, pass an override command after --.

Write a generated value file

hasp write-env --project-root . --target build.config --grant-convenience window

write-env --target is convenience materialization. It writes a workspace- visible file and requires explicit convenience approval. Prefer run or inject when the tool can receive env vars or broker-owned temp files.

Seed an app profile

hasp app connect server-dev --project-root . --target server.dev
hasp app run server-dev

app connect --target imports the target command and env/file mappings into a local app profile. The profile is local state; changing the manifest later does not silently rewrite the saved app profile.

Drift review

HASP stores a local review record for target expansion outside git. If a target later changes its command, refs, delivery set, or output paths, human CLI flows warn before continuing and hasp project doctor --json reports target_drift.

Agent and MCP surface

MCP target listing and explain are narrower than human CLI output. They return sanitized target names, descriptions, refs, delivery kinds, destination names, prerequisite status, and manifest identity. They do not return target command argv or secret values.