← Writing

Where did that build command come from?

Essay

A build command, the file it came from, and what to check when two sources disagree.

protocolmetadatamcpdeveloper-tools

Ask a repository metadata API how to build a project and it might return npm run build. Before using that answer, I want to know which file supplied it, when that file was checked, and whether another source gives a different command.

Those details belong with the value. They let a person or coding agent decide whether the answer fits the task or needs further inspection.

What I want alongside the answer

The command is only the start. I want six things from the response:

1. The selected value

Return the requested field and its selected value directly, even when the response includes other context.

2. Record status

Identify whether the record is canonical, reviewed, verified, imported, inferred, or draft, and explain what that status means. In dotrepo, verified can result from automated checks; it does not imply maintainer approval or establish that every field is correct.

3. Provenance

Show where the value came from and how it was obtained. A record can combine maintainer-declared identity with an inferred build command, so individual fields need sources and extraction methods where available.

4. Conflict context

When records disagree, show which one was selected, why it won, and how to inspect the alternatives. An empty conflict list only describes disagreements known to the system.

5. Freshness

Distinguish when the underlying record was checked from when the public snapshot was generated. Include the source revision and check times for individual fields where available. Publishing a new snapshot does not make an old record current.

Link to the repository, the selected record, and the evidence behind the answer. A consumer should be able to follow up without reconstructing those locations.

Working through a build query

The archived September 17 capture for ries-rs shows why these distinctions matter. The query and profile describe the same exported snapshot. These excerpts show selected fields from each response; the linked capture includes the full responses.

From the query:

{
  "path": "repo.build",
  "value": "npm run build",
  "conflicts": []
}

From the profile:

{
  "record": {
    "mode": "overlay",
    "generatedAt": "2026-09-16T16:31:27.131449Z"
  },
  "fieldEvidence": {
    "repo.build": {
      "checkedAt": "2026-09-16T16:31:27.131449Z",
      "confidence": "high",
      "method": "extracted",
      "source": "package.json",
      "state": "present"
    }
  }
}

The source tells a consumer where to inspect the command. In this capture, npm run build builds the WebAssembly package. The separately retrieved maintainer .repo names cargo build --release --locked for the native Rust build. A consumer asked for the native build should inspect that declaration and the source before choosing a command. The query’s empty conflict list does not establish that the two sources agree: the hosted response still selects the overlay.

The dates matter too. If the September 16 check is too old for the consumer’s task, a later export date cannot fix that. The consumer needs a new source check. Even when the answer is suitable, permission to execute it comes from the user’s task and environment, not from the metadata’s trust label.

Related Project

View all →