Project evidence
Understand the source revision, relationships, coverage and verification records Idam uses for a project.
Last updated 2026-10-02
What you'll achieve
- Read source and build provenance.
- Recognize stale or incomplete project context.
- Distinguish artifact, preview and release evidence.
Idam reads a bounded project snapshot and authorized operational records when a task is admitted. The snapshot identifies the saved source revision. An existing task keeps its admission evidence; a new task observes the current state.
Source relationships
Projection schema 6 extracts Python, JavaScript, TypeScript and TSX declarations using syntax parsers. Named functions, classes, methods and type declarations retain their file and parent-symbol references. Static imports and re-exports can identify a unique relative file candidate. Package, absolute, dynamic, ambiguous and unavailable imports are unresolved. A candidate is not proof of the runtime or bundler's resolution.
Next.js and Astro file-route conventions require a framework dependency in the nearest package. Inner package boundaries stop inheritance. Next.js private, parallel and intercepted app routes are excluded from this simple convention map. Astro templates are marked unsupported for syntax parsing even when their paths identify a route convention. Routes and test declarations never count as executed checks. Test titles and source bodies are not part of this metadata.
Source syntax inspection is limited to 48 files, 64 KiB per file, 512 KiB total, 20,000 syntax nodes per file and 96 relationships per file. The snapshot holds at most 2,000 facts. Protected, secret-screened, invalid, unsupported and bounded out syntax receives an explicit analysis state where space permits. Hitting the fact limit can also omit whole files or analysis records. This is a partial project graph, not complete semantic indexing or type checking.
Automatic source selection combines filename, symbol and route relevance and one-hop import/dependent candidates from at most four relevant files. It retains normal permission, protected-path, secret-screening and size checks. The selected source remains limited to eight files, 16 KiB per file and 24 KiB combined. Selected file metadata and nearby relationships are prioritized in the context.
Freshness and coverage
provenance records workspace, projector version and observation time.
projection_coverage reports file metadata and syntax-check counts for the
bounded snapshot, separately from the smaller set of facts included in the
model context. Zero projected files does not establish that the project contains
no excluded or unavailable files. application_health: not_assessed is explicit.
Project edits replace the current projection while retaining historical snapshots. Stable fact identifiers link changed facts; removed facts disappear from the new snapshot. Generation reconciliation rereads canonical state rather than applying old event payloads. Invalid source inventories, deleted projects and revoked access cannot yield a usable current context.
Recorded build evidence
frontend_build_state includes up to five recent private builds belonging to the
requester. It includes build/task/execution references, source revision, accepted
receipt and artifact digests, recorded status and timestamps. It excludes task
text, logs, source archives, provider details, storage keys and preview tokens.
Removed task content and another member's private builds are excluded.
matches_observed_workspace compares the build's immutable source revision with
the current saved project. Editing the source makes the old build historical;
its artifact remains tied to its original revision. artifact_bytes_verified
requires the matching stored artifact and accepted receipt. It only means the
artifact bytes were checked. application_checks and release_checks remain
not_observed until separate application or release evidence is available.
release_checks includes the latest release review for each included build. It
links the source revision, public release artifact, publication, deployment and
environment. A passed delivery record requires its source/review/publication
commitment and bounded HTTP observation to agree. Current source, active
destination, public address, policy and consent are compared separately; changes
mark the record stale while retaining its original observation time and status.
This is historical public homepage delivery, not a fresh health check or full
live application acceptance. Public response bodies, task content, deployment
secret snapshots and publication authority are never read into this view. Each
build adds at most one scalar metadata query and a current-policy lookup.
Backend-module compiler records and deployment pointers have independent provenance. Their artifact hashes alone cannot establish a match with the workspace or a working endpoint. Fixed diagnostics cite the exact observation revision that produced them. Absence of a diagnostic is not a health verdict.
The default context budget is 12,000 UTF-8 bytes. Omissions are explicit, and a diagnostic cannot survive without its cited evidence. All observations recheck current actor and project access; recorded evidence grants no permission to perform another build, read customer data or publish an application.
Application scenarios, when present, are frozen against the source, artifact and manifest. The project evidence reports each scenario index and screen, its status, completed steps and operation/frame digests. Inputs, target labels and scenario names are excluded. Missing or inconsistent records cannot support a passed status. These observations cover only the executed scenarios; they do not verify external integrations, untested behavior or a public release.
Help improve this page
Sign in to send page-specific feedback. For account-specific help, email support@blinkhost.me.