Live assessment · generated 2026-07-02 11:13:10 UTC · regenerate with php bin/aios-assess.php
Runtime prerequisites the app needs to boot.
Schema presence and whether reference data is loaded.
The locked v1 governance API surface.
Browser-facing pages and auth gating.
PHPUnit unit + integration coverage.
Ancillary tooling shipped in the repo.
Curated findings & fix status (from bin/aios-assess-bugs.json). Sorted: open first, then by severity.
| MEDIUM |
Root router.php is a Phase-1a stub (only /health) CFG-01
Config
index.php -> router.php only answers GET /health and 404s everything else with 'Phase 1a database foundation only.' The real app is split across src/web/index.php and src/api/index.php, which is undocumented and confusing as the apparent front door.
|
| MEDIUM |
Hardcoded API URL + undocumented two-server topology CFG-02
Config
src/web/index.php constructs APIClient('http://localhost:8080'). README documents ports 8000 (backend) and 3000 (frontend), which match neither the code nor each other. Running the UI requires two PHP servers (API on 8080, web on another port) plus MySQL, none of which is documented.
|
| LOW |
escalation_rules DB table is unused (rules hardcoded in PHP) CFG-03
Config
GET /governance/rules and the pipeline return 8 escalation rules sourced from PHP code even when the escalation_rules table is empty. The seeded table and the code list can drift apart with no single source of truth.
|
| CRITICAL |
Dev database 'aiosbuild' did not exist ENV-01
FIXED
Only 'aiosbuild_test' existed. The running app connects to 'aiosbuild' (per .env) and was dead on arrival until the DB was created and migrated.
✓ Created database + ran all 6 migrations (bin/migrate.php). |
| CRITICAL |
Seed data never loaded (directives / categories / rules empty) DATA-01
FIXED
directives, directive_categories, knowledge_pattern_categories, escalation_rules tables were all empty. Intent detection returned 0% confidence / 'No Matching Directive' for every request, gutting the core NL->directive product value. migrate.php does not load database/seeds/*.sql.
✓ Loaded database/seeds/*.sql (6 directives, 6 categories, 8 rules) AND fixed the root cause: bin/migrate.php now auto-runs bin/seed.php, which loads reference data when tables are empty. Fresh installs are runnable from migrate alone. |
| CRITICAL |
No user/role seed - login impossible out of the box DATA-02
FIXED
roles, users, permissions tables are empty after migration. The /governance and /governance/history web routes require Admin/Operator/Reviewer/Requester roles that do not exist, so no one can ever log in on a fresh install.
✓ Added bin/seed.php: seeds the 5 roles via RoleService and creates a bootstrap 'admin' user (default password admin1234, override via AIOS_SEED_ADMIN_PASSWORD) assigned Admin. Verified: POST /login -> 302 -> /governance. |
| CRITICAL |
session_start() never called - login always fails even with a valid user AUTH-01
FIXED
src/web/index.php never started a PHP session, so $_SESSION was empty on every request. The login CSRF token stored in $_SESSION['_csrf_token'] could never be validated, so POST /login always re-rendered the form (HTTP 200) instead of authenticating - login was impossible regardless of credentials. Found while verifying the DATA-02 seed.
✓ Added session_start() (httponly, SameSite=Strict) at the top of src/web/index.php before any output. Verified end-to-end: session cookie set, POST /login -> 302 -> /governance 200. |
| HIGH |
PHP 8.4 Deprecation warning leaks into API JSON response body API-01
FIXED
ErrorResponse::error() declared 'int $statusCode = null' (implicit nullable, deprecated in PHP 8.4). When the API is served directly (php -S src/api/index.php) display_errors is on, so a raw '<br /><b>Deprecated</b>...' HTML block was prepended to the JSON body on the first error after a cold start, corrupting the response for any JSON client. Would become a fatal TypeError in PHP 9.
✓ Changed signature to '?int $statusCode = null'. Verified cold-start error response is now clean JSON. |
| HIGH |
Confidence rendered as 6500% (0-1 vs 0-100 scale inconsistency) PIPE-01
FIXED
Root cause is a subsystem-wide scale inconsistency, not a one-line typo. The runtime + model contract use a 0-100 confidence scale (IntentClassification::validate() enforces 0..100; RuleEvaluator compares '< 70'; production emits 65), but the explainability subsystem (ExplainabilityService, ConfidenceExplanationBuilder, AuditTrailBuilder) was written for a 0-1 scale: it multiplied by 100 for display (-> 6500%), used '< 0.8'/'< 0.85' thresholds, and clamped overall confidence to min(1.0,...). The unit tests reinforced the mismatch by mocking 0-1 values (0.65, 0.85), so the suite never caught it.
✓ Standardized the explainability path on the authoritative 0-100 contract: removed the extra x100 in ExplainabilityService + ConfidenceExplanationBuilder + AuditTrailBuilder, changed thresholds to <80/<85, clamped overall to 100.0, and updated the 0-1 test fixtures/assertions across 4 test files to 0-100. Verified: live pipeline now shows 'confidence: 65%' and the full 527-test suite passes. |
mysql up & php bin/migrate.phpphp -S localhost:8080 src/api/index.phpphp -S localhost:8090 src/web/index.php → open http://localhost:8090/loginbin/aios-assess.php or findings in bin/aios-assess-bugs.json, then re-run.