Coding agents handle "add a field, show it on screen" fine. They
consistently miss the Android boundary around it:
Room/SQLite migrations that silently corrupt existing rows
A refresh coroutine owned by a view callback instead of the ViewModel
UI collection that keeps running after the Activity stops
Lifecycle/process-death paths nobody retested
None of it shows up as a compile error.
I built AI-Workflow to make those checks deterministic. You state
observable facts about a change and a checked-in registry maps them
to required specialist procedures:
Task classification: brownfield / android / safety
Detected concerns: concurrency, lifecycle, persistence, schema_migration
Recommended tier: COMPLEX
Required checks:
android-persistence-migration-readiness: because detected persistence, schema_migration
kotlin-coroutines-readiness: because detected concurrency
protected-lifecycle-transaction-review: because detected lifecycle
android-runtime-evidence-readiness: because detected lifecycle
No LLM judgment in that mapping — it's a registry lookup, same output
every run, every agent.
Install takes one command, no clone needed:
uvx --from git+https://github.com/RanaAhmedHamdy/AI-Workflow.git \
ai-workflow brownfield --platform android --profile safety \
--target /path/to/your-android-app --dry-run
There's also a lightweight Safety profile that gives you just the
routing + protected-boundary checks without requiring a full feature
lifecycle. And a full Android fixture (SQLite migration fallback,
ViewModel coroutine ownership, lifecycle-aware Flow collection) with
unit tests and debug build verified locally.
Pre-v1, Apache-2.0, honest about what's claimed vs unclaimed.
Top comments (1)
The registry lookup is the part I’d preserve as an explicit decision artifact, not just a routing implementation detail. For each run, record the observable fact set that was supplied, the registry version (or digest), and the resulting required-check set. Then a later reviewer can answer not only “which checks ran?” but “why were these exact checks mandatory under the policy that existed at that time?”
I’d also keep classification and enforcement separate. The fact extractor can be heuristic or evolve over time, but once facts are resolved, the mapping from facts to mandatory procedures should stay deterministic and fail closed when the registry cannot resolve them. That gives you a useful boundary: probabilistic interpretation may propose the state, while the checked-in policy decides the obligations.
It also makes regression tests much stronger: a policy change can be diffed as a change in required obligations rather than merely a change in agent behavior.