tylerg/auth-yes
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
auth-yes/forum/poc-g2/BOUNDARIES.md
Tyler Gillispie 555c5eb384
feat(forum): add missing Gen 1 & Gen 2 PoCs with strict constraint enforcement (#69) 
This commit implements the missing Proof of Concepts (PoCs) required by the `agent-forum-v4` architecture blueprint as identified in `CONCEPTS.md`.

Updates include:
- `execution_flywheel_poc.ts`: Implemented mock version (Gen 1) using in-memory state and physical version (Gen 2) utilizing actual file I/O tracking to prove state management bounds.
- `tool_sandbox_poc.ts`: Implemented mock version (Gen 1) yielding simulated telemetry and physical version (Gen 2) utilizing real production-grade tool invocations (Semgrep via CLI and Tree-sitter via WASM module).
- `git_hooks_poc.ts`: Implemented mock version (Gen 1) intercepting simulated events and physical version (Gen 2) configuring a physical Git temp directory executing native `.git/hooks/pre-commit` hooks.
- `BOUNDARIES.md`: Documented explicit technical boundaries in both `poc-g1` and `poc-g2` to enforce strict isolation vs production file-system operation.
- Fixed Deno Linting constraints across `poc-g2/` scripts.
- `CONCEPTS.md`: Status flags updated to ✅.

Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com>
Co-authored-by: mrteye <1945243+mrteye@users.noreply.github.com>
2026-08-29 00:28:19 -07:00

994 B
Raw Blame History

Generation 2 Constraints: Production-Grade Tooling, Physical Limits

The Proofs of Concept (PoCs) in this directory (forum/poc-g2/) are designed to prove the physical feasibility of the architecture using actual, production-ready tools.

  1. No Faking: We are explicitly not faking or mocking tools "to save on repo bloat." If the architecture calls for Tree-sitter or Semgrep, these PoCs must demonstrate their execution using actual binaries or WASM payloads.
  2. Physical File I/O: These scripts interact with the actual filesystem (e.g., tracking states via real JSON files, parsing real Markdown or YAML, dynamically creating physical temp Git repos) to prove constraints.
  3. Architectural Validity: If a required tool is too heavy or fundamentally incompatible with the Local-First/Git-Native bounds (as proven in the Graveyard PoC), it must be flagged for architectural reevaluation. The ability to run the real tool locally is the core pass/fail criterion of Gen 2.