- 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.
		
			
				
	
	
	
		
			1.1 KiB
		
	
	
	
	
	
	
	
			
		
		
	
	
			1.1 KiB
		
	
	
	
	
	
	
	
Entry-Point Runtime — Deno
Signals to gather
- argv0equals- denoor path ends with- /bin/deno.
- Arguments include run,task,serve, orcompileoutputs.
- 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 compileexecutables and the Deno runtime invoking a script.
- Recognise deno task <name>by reading tasks fromdeno.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 compileemits a standalone binary, treat it as C/C++ unless metadata persists.