Skip to content

appforge-studio.boundary-model.md

Latest commit

 

History

History
86 lines (62 loc) · 4.21 KB

appforge-studio.boundary-model.md

File metadata and controls

86 lines (62 loc) · 4.21 KB
Raw

Generated App Publish Boundary Model

Purpose

This document closes public issue #3: Define the app generation review gate before generated code can be published.

It provides concrete agentic-enterprise evidence for AppForge Studio. The repo remains independent: it is not an AAIF project, not a Linux Foundation project, and not endorsed by either organization.

High-Risk Action Boundary

Prompt-to-app generation, generated code mutation, sandbox preview execution, dependency installation, app export, and any publish action that moves generated work outside the review workspace.

Actors

Actor Responsibility
Product builder Owns the product brief, generated application scope, and publishing intent.
App reviewer Reviews generated code, dependencies, secrets, license posture, and runtime behavior.
AI app generator Proposes code, assets, dependencies, and configuration but cannot approve publishing.
Sandbox runtime Executes previews and validation inside a bounded environment.
Maintainer Reviews provider fallback, audit evidence, and contribution safety.

Identity Boundary

  • Every generated project must have a human owner and declared tenant or workspace.
  • The AI app generator cannot own secrets, install packages silently, or publish generated code.
  • Preview tokens, provider credentials, and deployment targets must be referenced through secret bindings.
  • Generated artifacts must preserve prompt lineage, source template, provider, dependency list, and review state.

Tool And Action Boundary

Action Boundary
generate_app Allowed only from a declared brief, template scope, and workspace owner.
run_preview Must execute in a sandbox with no production credentials or deployment permissions.
install_dependency Requires license and purpose review before it is added to the generated app.
modify_generated_code Draft until human review confirms the diff and runtime intent.
publish_app Requires human approval, secret scan, dependency review, and export audit event.

Human Approval Gates

  • Before generated code is exported, published, or deployed.
  • Before adding dependencies, plugins, provider SDKs, or generated secrets/config files.
  • Before connecting a generated app to production data or identity providers.
  • Before promoting a preview into a persistent customer, employee, or partner-facing workspace.
  • Before deleting audit evidence for generation, review, or publishing decisions.

Audit Event Model

Event Minimum Evidence
app_generation.requested workspace, human owner, prompt hash, template id, provider
sandbox.preview_started generated app id, runtime image, network policy, reviewer state
dependency.proposed package, version, license, purpose, source
generated_code.reviewed reviewer, diff summary, findings, approval state
app_publish.approved approver, destination, secret scan status, dependency review status

Local Proof Path

  • npm install to prove dependency resolution.
  • npm run lint to prove static project health.
  • npm run test for generation, dependency, approval, and audit fixtures when available.
  • npm run build to prove the application compiles.
  • Use synthetic prompts and generated demo apps in public proof; never use customer prompts, private source, or real secrets.

OSS And Self-Hosted Fallbacks

  • Use local Docker or devcontainer-based previews before paid remote sandbox providers where feasible.
  • Keep hosted sandbox, queue, billing, and deployment providers behind explicit adapters.
  • Store generation, review, and publish events in PostgreSQL or SQLite fixtures before hosted audit products.
  • Prefer OSS template libraries and static analyzers for public examples.

Contributor Follow-Up

Add a small generated-app fixture that records prompt hash, template id, dependency proposal, sandbox preview result, reviewer decision, and publish status.

Issue Closure Evidence

This document satisfies the issue checklist by separating:

  • identity or actor boundary
  • tool/provider/action boundary
  • human approval or escalation point
  • audit or observability events
  • OSS/self-hosted fallback direction
  • validation and static inspection path