- clarification: alkcall is a library others build on; alkgen branches
1+2 are a dev tool generating static files into downstream projects
(protocol crates alktty/alktunnels/sftp, cloud integrations vast.ai/
runpod) from provided schemas (BAST or jsonschema/openapi)
- OQ-GN-01 resolved: module-level output for v1; fragments out
(defeats dev-tool purpose), crate generation out for v1 (composed
from modules later if asked). Residue: file partitioning policy
- OQ-GN-06 reframed: generated files land in projects that don't
depend on alktype today, so dependency footprint is consumer's
choice, not wire-shaped; leaning self-contained, POC decides
- branch 2 reframed: static counterpart of alkhttp from_* adapters
- plans for offsets/sizes (already computed+validated by the engine,
free at generation time since alktype is already a dep), BAST for
descriptive metadata; drift risk inverts into ordinary
dependency-upgrade tracking of alktype's plan API
- residue: exact plan->context projection is the Phase 1 context-
builder spec task
- OQ-GN-03 resolved as posture: interpreter/compiler duplication is
the point (dynamic vs static deployment profiles); alktype near
schema-method floor, ~20x off hand-rolled; alkgen's value prop is
recovering most of that gap. Drift stays the standing risk.
- OQ-GN-08 POC 1 calibration: three-way benchmark (plan-walk vs
generated vs hand-rolled) doubles as drift check + perf validation;
OQ-GN-05 boundary reframed as performance trade