- 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.2 KiB
		
	
	
	
		
			Markdown
		
	
	
	
	
	
			
		
		
	
	
			23 lines
		
	
	
		
			1.2 KiB
		
	
	
	
		
			Markdown
		
	
	
	
	
	
| # Entry-Point Runtime — Elixir / Erlang (BEAM)
 | |
| 
 | |
| ## Signals to gather
 | |
| - `argv0` equals `elixir`, `iex`, `mix`, `erl`, `beam.smp`, or release scripts (`bin/app start`).
 | |
| - Release layouts: `_build/prod/rel/<app>/bin/<app>`, `releases/<version>/vm.args`, `sys.config`.
 | |
| - Environment variables (`MIX_ENV`, `RELEASE_COOKIE`, `RELEASE_NODE`).
 | |
| - Config files (`config/config.exs`, `config/prod.exs`).
 | |
| 
 | |
| ## Implementation notes
 | |
| - Recognise Distillery / mix release scripts that `exec` the real BEAM VM.
 | |
| - When release script is invoked with `eval`, treat the wrapper as part of the chain but classify runtime as `Elixir`.
 | |
| - Inspect `vm.args` for node name, cookie, and distributed settings.
 | |
| - For pure Erlang services (no Elixir), the same detector should fire using `erl` hints.
 | |
| 
 | |
| ## Evidence & scoring
 | |
| - Boost for release directories and BEAM VM binaries (`beam.smp`).
 | |
| - Add evidence for config files and env vars.
 | |
| - Penalise minimal images lacking release artefacts (could be generic shell wrappers).
 | |
| 
 | |
| ## Edge cases
 | |
| - Phoenix apps often rely on `bin/server` wrapper—ShellFlow must collapse to release script.
 | |
| - Multi-node clusters may start multiple BEAM instances; treat as `Supervisor` if several nodes stay active.
 |