Project Adoption Rules

How to inspect and adopt an existing codebase before changing it.

v1StandaardTerug naar overzicht

Inhoud bewerken

Pas de instructie aan. Opslaan maakt een nieuwe versie en is terug te draaien.

Gelijk aan standaard

Voorbeeld

De huidige opgeslagen inhoud.

Toon inhoud (2.276 tekens)

# Project Adoption Rules

How Assembly Hangar analyzes and adopts existing projects or codebases.

Do not blindly rebuild an existing project. First understand and adopt what
already exists. For an existing or loaded project, the AI should derive the goal
(step 1) and the analysis (step 3) from the codebase and documentation as much
as possible.

Questions about the actual technology stack are repository facts, not user
checklist items. Before asking the user which programming languages,
frameworks, build tools, package manager, database, tests, CI/CD or deployment
the project uses, the Code Retrieval/adoption flow must inspect repository
evidence such as manifest files, lockfiles, tsconfig, framework configs,
Docker/Vercel/GitHub Actions files and README content. The output must state the
found stack and exact install/test/build commands, then let the AI Prompt &
Evaluation Agent and Orchestrator judge whether the current stack is adequate or
whether a migration/change is justified.

The same audit engine is used at two moments (same discipline, different scope):
as the intake baseline when a codebase is loaded on step 1, and as the repo-wide
quality gate on step 12 before release. Both runs execute real scanners in an
isolated sandbox (dependencies, secrets, SAST, vulnerable config) and produce
structured findings with severity plus a quality + security score.

## What to inspect
Product goal, current status, tech stack, folder structure, routes and pages,
API endpoints, data models, database and schema, authentication, permissions,
integrations, environment variables, UI components, styling system, state
management, tests, exact install/test/build commands, build process, deployment process, documentation, changelog,
technical debt, broken flows, UX confusion, duplicated logic, dead code, missing
settings, missing validation, risky areas.

## Output of a codebase scan
1. Project summary
2. Current state
3. Stack overview
4. Main modules
5. Working areas
6. Broken or risky areas
7. UX and navigation issues
8. Missing documentation
9. Technical debt
10. Recommended priorities
11. Agent-ready task list
12. Validation plan

The result should be a clear project health overview and an actionable
improvement plan that maps onto the pyramid.

# Project Adoption Rules How Assembly Hangar analyzes and adopts existing projects or codebases. Do not blindly rebuild an existing project. First understand and adopt what already exists. For an existing or loaded project, the AI should derive the goal (step 1) and the analysis (step 3) from the codebase and documentation as much as possible. Questions about the actual technology stack are repository facts, not user checklist items. Before asking the user which programming languages, frameworks, build tools, package manager, database, tests, CI/CD or deployment the project uses, the Code Retrieval/adoption flow must inspect repository evidence such as manifest files, lockfiles, tsconfig, framework configs, Docker/Vercel/GitHub Actions files and README content. The output must state the found stack and exact install/test/build commands, then let the AI Prompt & Evaluation Agent and Orchestrator judge whether the current stack is adequate or whether a migration/change is justified. The same audit engine is used at two moments (same discipline, different scope): as the intake baseline when a codebase is loaded on step 1, and as the repo-wide quality gate on step 12 before release. Both runs execute real scanners in an isolated sandbox (dependencies, secrets, SAST, vulnerable config) and produce structured findings with severity plus a quality + security score. ## What to inspect Product goal, current status, tech stack, folder structure, routes and pages, API endpoints, data models, database and schema, authentication, permissions, integrations, environment variables, UI components, styling system, state management, tests, exact install/test/build commands, build process, deployment process, documentation, changelog, technical debt, broken flows, UX confusion, duplicated logic, dead code, missing settings, missing validation, risky areas. ## Output of a codebase scan 1. Project summary 2. Current state 3. Stack overview 4. Main modules 5. Working areas 6. Broken or risky areas 7. UX and navigation issues 8. Missing documentation 9. Technical debt 10. Recommended priorities 11. Agent-ready task list 12. Validation plan The result should be a clear project health overview and an actionable improvement plan that maps onto the pyramid.