feat(adf): typed-data-access policy module + named-scaffold registry (#69 Session 1)#96
Merged
stackbilt-admin merged 2 commits intomainfrom Apr 9, 2026
Merged
Conversation
added 2 commits
April 9, 2026 14:08
…69) Session 1 of charter#69 — typed data access + ontology enforcement policy. Ships the policy module and the infrastructure for consumer repos to adopt it via `charter adf create typed-data-access`. ## What this lands - **`.ai/typed-data-access.adf`** — dogfood module for charter itself. Documents the canonical data registry, 6 sensitivity tiers (public, service_internal, cross_service_rpc, pii_scoped, billing_critical, secrets), the disambiguation protocol, and the load-bearing access constraints (e.g., never leak billing_critical over RPC, HALT on undefined concepts instead of guessing). - **`.ai/manifest.adf`** — new ON_DEMAND entry so charter's own dev agent loads typed-data-access whenever work touches tenant/user/ subscription/quota/sensitivity/DATA_AUTHORITY/etc. keywords. - **`TYPED_DATA_ACCESS_SCAFFOLD` export in adf.ts** — the scaffold template as a reusable const, so consumer repos can adopt the policy with a single command. - **`NAMED_MODULE_SCAFFOLDS` registry + `NAMED_MODULE_DEFAULT_TRIGGERS`** — extensible map that `buildModuleScaffold` and `adfCreate` consult before falling back to the generic empty scaffold. First entry is typed-data-access; follow-up sessions can add more canonical modules (governance policies, compliance checks, etc.) behind the same mechanism. - **`adfCreate` change** — when the module name matches a named scaffold and no explicit `--triggers` is provided, the default trigger set is auto-applied so `charter adf create typed-data-access` produces a fully-wired ON_DEMAND entry with 16 business-concept keywords. ## What this does NOT land (Session 2+) - Charter governance check that flags references to unregistered terms (requires classify/validate integration) - `charter doctor` check for unregistered concepts - Codebeast DATA_AUTHORITY wiring - AEGIS disambiguation firewall integration with the canonical registry path (already consumes a build-time snapshot — see aegis web/src/lib/data-registry.ts — but doesn't hot-reload from charter) - Auto-scaffold via `charter bootstrap` (opt-in only via `charter adf create` for now — not every repo needs ontology enforcement) ## Validation - 9 new unit tests covering named scaffold registry, default triggers, sensitivity tier presence, registry path reference, and the load-bearing disambiguation constraint - 354/354 tests passing (+9 from 345) - End-to-end verification in a clean temp repo: `charter adf create typed-data-access` writes the rich scaffold AND registers it in ON_DEMAND with the 16 default triggers, no explicit flags needed - Full typecheck + build clean ## Known issue (pre-existing, not fixed here) Empty `📂 ON_DEMAND:` sections in a manifest cause `charter adf create` to fail with "ON_DEMAND must be a list section in manifest.adf" because the parser sees an empty key as a non-list. Workaround: manifests need at least one ON_DEMAND entry before `adf create` can append. Worth filing as a separate issue since it affects any `adf create` usage. ## References - Closes part of #69 (Session 1 of 4) - Registry source of truth: Stackbilt-dev/stackbilt_llc/policies/data-registry.yaml - Downstream: aegis web/src/lib/data-registry.ts (compiled consumer), aegis web/src/lib/disambiguation.ts (runtime firewall) - Related: codebeast#9 (DATA_AUTHORITY), aegis#344 (disambiguation)
adf_commands_loc: 884 / 800 → 796 / 800. The TYPED_DATA_ACCESS_SCAFFOLD + NAMED_MODULE_SCAFFOLDS + NAMED_MODULE_DEFAULT_TRIGGERS blew the 800-line ceiling on packages/cli/src/commands/adf.ts when folded inline. Moved them to a dedicated adf-named-scaffolds.ts alongside the other adf-*.ts module files. adf.ts imports the maps for use by buildModuleScaffold and adfCreate, and re-exports them for backward compat with programmatic consumers + tests. This also sets up a clean pattern for adding more named scaffolds in future sessions (Session 2+ can add scaffolds for governance policies, compliance modules, etc. to adf-named-scaffolds.ts without touching adf.ts again).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Session 1 of #69. Ships the typed data access + ontology enforcement policy as a charter ADF module, plus the named-scaffold registry infrastructure that lets consumer repos adopt it with `charter adf create typed-data-access`.
Scope boundaries
In: policy module content, scaffold wiring, default triggers, tests, charter self-dogfood
Out: governance check for unregistered terms, doctor integration, codebeast DATA_AUTHORITY wiring, AEGIS firewall hot-reload from charter, bootstrap auto-scaffold (all deferred to Sessions 2-4)
What ships
Policy module
Scaffold registry infrastructure
Validation
Unit tests (9 new, 354 total)
End-to-end test in a clean temp repo
```bash
$ charter adf create typed-data-access
[ok] Created .ai/typed-data-access.adf
[ok] Registered typed-data-access.adf in ON_DEMAND
$ cat .ai/manifest.adf
...
📂 ON_DEMAND:
```
Single command produces rich scaffold + fully-wired 16-keyword ON_DEMAND entry. No explicit flags needed.
Full suite
Known issue (pre-existing, not fixed here)
Empty `📂 ON_DEMAND:` sections cause `charter adf create` to fail with "ON_DEMAND must be a list section in manifest.adf" because the parser sees an empty key as a non-list. Workaround: manifests need at least one ON_DEMAND entry before `adf create` can append. This affects any `adf create` usage, not just named-scaffold modules — worth filing as a separate issue.
Next sessions (#69 roadmap)
References
🤖 Generated with Claude Code