Ai Olympus Laravel Package

Technical Evaluation

Architecture fit

pekral/ai-olympus remains a dev-only Composer package with zero product-runtime footprint: no service provider, routes, migrations, or runtime dependency. The architectural judgement still belongs to the delivery architecture — agent workflow, CI, and the merge gate.

What changed in 0.1.3 is the size and shape of that process surface, in three ways that matter to a TPM:

1. The agent roster appears to have changed. The 0.1.2 assessment documented daedalus/athena at high reasoning and hephaestus/argus/hermes at medium. 0.1.3 ships a "Ninja Turtles agent team" and describes leonardo, donatello, raphael, splinter, and a new casey. If this is a replacement rather than an addition, every named handoff, brief reference, and escalation path a team learned on 0.1.2 has moved. A rename inside a patch release is a process migration wearing a bugfix label.
2. Agents now mutate the developer environment. interactive-testing gained a Local readiness section that prepares the checkout, installs dependencies from lock files, migrates the local database, refreshes caches, builds front-end assets, starts application processes, and cleans up (stopping processes, returning to the starting branch, deleting a branch it created). The documented guardrails are sensible — local target only, project's own documented commands, no tracked-file edits, no discarding uncommitted changes, git pull --ff-only — but the package has crossed from "instruction files and issue loaders" into "supervised local-run harness." That is a new trust boundary with the developer machine, not just with the tracker.
3. New hard limits and new scripts. A 5,000-token skill body limit now sits alongside the 150,000-character loader limit, enforced via composer build/skill-check. New shell tooling appears (classify-risk.sh owning the tier, scripts/run-shell-self-tests.sh, composer shell-self-tests). The package now ships executable logic that must be tested and owned, not only prose.

The gate's judgement surface also widened: a new Critical class (duplicate Action, or a repeated two-or-more-step sequence, detected across every Action under app/Actions/**), a new Moderate class (subclass override copying a parent body), and a severity downgrade for refactoring behaviour changes (Critical → Moderate, still blocking, with the S1–S3 security carve-out preserved). Adopting 0.1.3 means adopting a materially stricter review model than 0.1.2.

Integration feasibility

Install is unchanged: one Composer command plus a binary invocation, still targeting a Laravel/PHP repo on Composer, GitHub via gh, and JIRA via acli. The hermetic fake-binary test harness described for the loaders is still the strongest portability signal in the release history.

New feasibility friction:

• casey / MySQL. The MySQL advisory report runs mysql-problem-solver with MODE=cr-report, dispatched by splinter once per diff after convergence, when the diff touches database operations on MySQL/MariaDB or an unresolved engine. Whether it needs credentials or connectivity to the reviewed application is not stated — that determines whether it can run on a CI runner or only on a developer machine.
• interactive-testing readiness. It assumes the project has documented, deterministic commands for install, migrate, cache, and asset build. A repo without that discipline gets blocked scenarios (the notes say an item that cannot be made ready blocks only the scenarios that depend on it — scoped correctly, but the value degrades).
• Prior blockers remain unanswered. The 0.1.2 assessment's most important asks — the PHP/Laravel support matrix, --prune deletion semantics, and a regression test for the merge-gate trust boundary — are not addressed anywhere in these notes. 0.1.3 adds scope without closing them.

Technical risk

• Environment-mutating agent behaviour (new, highest severity). Dependency installs, migrations, cache rebuilds, process starts, and branch deletion are now inside the agent loop. The cleanup story is documented, which is the right instinct, but there is no mention of a dry-run flag, a command allowlist, or a --no-prepare mode. A bug here damages developer state, not production — but it damages trust in the tool fastest.
• Cross-codebase DRY as a blocking Critical (new). Comparing every new or changed Action against every Action under app/Actions/** is a superlinear review surface and a false-positive generator: "a sequence of two or more steps that another flow repeats" is a judgement call, and a Critical finding blocks the merge. The notes show real care in scoping (a repeated sequence is one finding listing every copy; the Action scope bullet keeps only logic no other flow repeats yet; inline validation/mapping/queries stay with their own bullets). That is evidence of iteration against double-finding, not evidence of a regression test.
• Severity downgrade for refactoring (net positive, verify the carve-out). Behaviour change in a refactoring-only change is now Moderate, still blocking, never deferred at round 3, with S1–S3 security keeping its security severity. The intent is right. The question is whether the carve-out is mechanically derived from the risk tier or left to agent judgement.
• Advisory path separation (good design). casey's MySQL report never enters review counts, the convergence gate, or the merge gate, and a caller that cannot dispatch writes an explicit MySQL report not run — dispatch casey. That is a visible-degradation pattern — exactly what the JIRA loader's silent empty-list fallback still lacks.
• Skill-body overflow. Two skills were split into reference files to fit 5,000 tokens with no rule change and no text dropped, and composer build now fails/warns on the limit. Good hygiene, but headroom per skill is unstated and the limit is tighter than the loader limit.
• Pre-1.0 instability, now demonstrated. Three patch releases in the observed window, each changing process behaviour, one changing the agent cast. Treat file layout, agent names, rule paths, and CLI flags as unstable regardless of semver.

Key questions

1. Does 0.1.3 close any of the open 0.1.2 items — PHP/Laravel support matrix, --prune deletion semantics, and a regression test for the merge-gate trust boundary? Nothing here suggests it does.
2. Is the Ninja Turtles team a replacement for daedalus/athena/hephaestus/argus/hermes, or an addition? If replacement, what is the remap for a team already standardised on the old names, briefs, and ledgers?
3. Does interactive-testing support a dry-run or read-only readiness check, and what is the allowlist of commands it may execute? How does it determine "the project's own documented command" — checked-in config, or inference?
4. Is there a regression test for the cross-codebase Action DRY rule that pins the false-positive boundary, particularly "a sequence of two or more steps another flow repeats"?
5. Does casey require database connectivity or credentials, and can it run on a CI runner?
6. What is the per-file headroom against the 5,000-token skill limit after the reference splits?
7. Do the new shell self-tests cover classify-risk.sh and run-shell-self-tests.sh, and does the package CI run them?
8. Is the S1–S3 security carve-out in refactoring review derived mechanically from classify-risk.sh, or from agent judgement?

Integration Approach

Stack fit

Unchanged core: Laravel/PHP on Composer, GitHub via gh, JIRA via acli. 0.1.3 adds two implicit prerequisites — a MySQL/MariaDB surface for casey (or acceptance that the advisory report is skipped, which the callers do surface), and a locally reproducible project setup for interactive-testing readiness. Teams outside the Composer/GitHub/JIRA trio still get the agent and rule layer only.

Migration path

0.1.2 → 0.1.3 is a semver patch with a process-level change. Treat it as a migration:

1. Branch scratch, run composer require pekral/ai-olympus:0.1.3 --dev then vendor/bin/ai-olympus install --force --prune, and diff every agent, rule, skill, and script file.
2. Reconcile agent names and handoff references; grep the repo for old agent identifiers before merging.
3. Re-run the gate against an in-flight PR before committing the bump, so the new Critical and Moderate classes surface in a controlled setting rather than on someone's deadline.
4. Pin the exact tag. A package that rewrites instruction files and adds executable scripts on install must never float.

Compatibility

Still unverified from the release notes, and now with more to verify: PHP and Laravel constraints, gh and acli versions and auth modes, MySQL/MariaDB access requirements for casey, and whether the composer scripts and scripts/ files collide with project-owned entries. The loader harness fakes the CLIs; production CI needs the real ones, plus whatever interactive-testing requires — which by design should not be CI.

Sequencing

1. Get written answers to the carry-over questions (support matrix, --prune semantics, trust-boundary test). Do not bump on an unanswered base.
2. Pilot bump on one repo, gh only, casey disabled, interactive-testing not yet enabled. Diff everything.
3. Exercise the DRY Critical rule deliberately: one PR with a known duplicate Action, one clean PR. Measure findings against reality before the rule can block real work.
4. Enable interactive-testing on one developer machine against a disposable branch and database; confirm cleanup restores branch, processes, and files. Only then broaden.
5. Add casey last — it is advisory and gate-free, so it is the lowest-risk change in the release.
6. Establish the --force --prune update ritual (branch, diff, review, merge) before the package reaches a second repo.

Operational Impact

Maintenance

More artifacts to own than before: agent definitions across two runtimes (agents/*.md and codex/agents/*.toml), a growing set of reference files per skill, a tier classifier script, and shell self-tests. Two enforced ceilings (150k characters per instruction file, 5k tokens per skill body) now produce build-time signals that someone must own. Upstream cadence is high and substantive — 0.1.1 superseded almost immediately, 0.1.2 superseded by a patch that reworked the agent team and the review rules. Budget a real review per bump, not a version-number edit.

Support

Support now splits three ways: CLI authentication (gh, acli), merge-gate judgement calls (with a wider set of blocking classes), and — new — local environment preparation. The third generates a distinct ticket type: "the agent changed my machine." That lands on whoever owns agent configuration, not the maintainer. Name an owner for each of the three before rollout. The MySQL report not run — dispatch casey convention is a good model for how the other degradation paths should report.

Scaling

Two scaling properties are worth naming explicitly. First, the cross-codebase Action DRY scan scales with the size of app/Actions/**, not with the diff — review latency and token cost grow as the codebase grows, and the false-positive rate likely grows with it. Second, cost: casey runs once per qualifying diff after convergence, blast-radius analysis adds depth on STANDARD and CRITICAL, and the FAST tier is the only valve that skips it. As repos and engineers multiply, that cost is linear in usage and still hand-tuned in configuration. The file-based shared brief and ledgers remain a contention point for large multi-team orgs.

Failure modes

• Destructive local preparation. interactive-testing runs installs, migrations, and branch deletion on a developer machine. Cleanup is documented; a partial failure mid-run is not described as recoverable.
• False-positive Critical from cross-codebase DRY. Blocks a merge on a judgement call about repeated sequences. Highest-probability source of "why is my PR blocked" escalations in this release.
• Silently unrun MySQL report. Mitigated by the explicit caller message; residual risk is that nobody reads it, producing false confidence in DB-heavy diffs.
• Refactoring behaviour change downgraded to Moderate. Still blocking, still non-deferrable at round 3, which is the right shape — but a downgrade in a patch release is a gate-tightness change reviewers must be told about.
• Instruction/skill overflow. Now caught at build for skills; loader headroom on the largest agent files remains thin.
• Persistent silent under-enforcement. The JIRA loader's empty-list fallback on comment-fetch failure is unchanged, with no operator-visible signal described. This remains the failure most likely to let a bad merge through while everyone believes the gate ran.
• Agent roster churn. Old agent names in team docs, prompts, or scripts break or no-op without a version-major signal.
• Destructive install. --force --prune on an unpinned bump can still overwrite or remove local customisations with no reviewable diff.
• CLI/tooling drift. gh, acli, MySQL client, or shell version changes alter behaviour with no corresponding change in this package.

Ramp-up

Higher than at 0.1.2. A new engineer must now absorb the agent team and its handoffs, the FAST/STANDARD/CRITICAL tiers and their depth rules, three evidence grades (Verified, Likely, Unknown), the YAML impact report format, the untrusted-tracker-content boundary, and the readiness contract for interactive testing. Estimate a sprint for the ledger and dispatch conventions plus meaningful time on the review rules — onboarding quality depends on whether the README was updated alongside the roster change, which these notes do not confirm.

Recommendation: Do not auto-bump. Adopt 0.1.3 only after the carry-over questions from 0.1.2 are answered in writing (PHP/Laravel support matrix, --prune semantics, gate trust-boundary test), and then behind a single-repo pilot with casey and interactive-testing disabled. Gate the wider rollout on two measurements: the false-positive rate of the cross-codebase DRY Critical rule against known-good PRs, and a verified cleanup run of the interactive-testing readiness preparation. The release contains genuinely good engineering — advisory-versus-blocking separation, explicit degradation messages, scoped findings to prevent double-reporting, and severity reasoning on refactoring — but it also widened the gate, changed the agent cast, and put environment mutation inside the loop, all under a patch version. The silent JIRA degradation path and the unanswered support matrix remain the two items that should block adoption regardless of how good the rest is.