e8537460a3
- Introduced AGENTS.md, README.md, TASKS.md, and implementation_plan.md for Vexer, detailing mission, responsibilities, key components, and operational notes. - Established similar documentation structure for Vulnerability Explorer and Zastava modules, including their respective workflows, integrations, and observability notes. - Created risk scoring profiles documentation outlining the core workflow, factor model, governance, and deliverables. - Ensured all modules adhere to the Aggregation-Only Contract and maintain determinism and provenance in outputs.
23 lines
1.1 KiB
Markdown
23 lines
1.1 KiB
Markdown
# Entry-Point Runtime — Deno
|
|
|
|
## Signals to gather
|
|
- `argv0` equals `deno` or path ends with `/bin/deno`.
|
|
- Arguments include `run`, `task`, `serve`, or `compile` outputs.
|
|
- Presence of `deno.json` / `deno.jsonc`, `import_map.json`, or cached modules (`/deno-dir`).
|
|
- Environment (`DENO_DIR`, `DENO_AUTH_TOKENS`).
|
|
|
|
## Implementation notes
|
|
- Resolve script URLs or local files; for remote sources record the URL as evidence.
|
|
- Distinguish between `deno compile` executables and the Deno runtime invoking a script.
|
|
- Recognise `deno task <name>` by reading tasks from `deno.json`.
|
|
- ShellFlow should already collapse Docker official entrypoint (`/usr/bin/env deno task start`).
|
|
|
|
## Evidence & scoring
|
|
- Boost for confirmed script/URL and config file presence.
|
|
- Add evidence for permissions flags (`--allow-net`, `--allow-env`) to aid policy decisions.
|
|
- Penalise when only the binary is present without scripts.
|
|
|
|
## Edge cases
|
|
- Deno deploy shims or adapters may further wrap the runtime; rely on wrapper catalogue.
|
|
- When `deno compile` emits a standalone binary, treat it as C/C++ unless metadata persists.
|