The full product specification.

Product: Appvecta · Company: Globevik Category: AI-native mobile engineering environment Status: In development. Phase 0 (technical spike) closed 18 September 2026. Private alpha targeted January 2027. Initial targets: Native Android (Kotlin/Java) and Flutter on Android.

1. What Appvecta is

Appvecta is an engineering environment for mobile projects, built around one promise:

Appvecta understands how a mobile project is connected, helps you make a change, runs the application, tests the real user flow, and shows evidence of what passed or failed.

It is not an editor with an AI chat box added. It is a closed loop:

Understand → Plan change → Modify code → Build and run → Operate app → Collect evidence → Report or fix → (back to build)

That loop is the product. Everything else supports it.

How it is delivered

• A branded Code-OSS distribution (a VS Code-family IDE) with the Appvecta extension built in.
• The same extension also runs in stock VS Code.
• A local Appvecta Engine process does the real work: scanning, the project graph, agents, device control, QA and reports. The extension talks to it over JSON-RPC.
• A small appvecta command-line tool for debugging and CI.

2. The problem

To ship one small change on a mobile app, a developer today has to:

• understand an unfamiliar architecture;
• find every file affected by a feature or bug;
• explain project context to an AI assistant, again, every session;
• switch between editor, terminal, Android Studio, emulator, logcat and test tools;
• tell an agent what to tap, one step at a time;
• reproduce failures manually;
• collect screenshots and logs by hand;
• confirm the AI-generated change did not break a different flow.

Those activities are disconnected. Appvecta connects them with a persistent, locally stored model of the project.

3. Who it is for

1. Solo Android and Flutter developers using AI coding agents.
2. Small mobile teams with no dedicated QA engineer.
3. Developers maintaining unfamiliar or legacy Kotlin/Java projects.
4. Agencies that repeatedly build and test similar mobile workflows.
5. Later: Android POS and enterprise-device developers.

4. The six named features

5. Appvecta Brain

A local graph of the project, built by reading the code — never by running the build.

What it knows

Shared: files, packages, modules, classes, interfaces, methods, functions, fields, annotations; definitions, references, imports, inheritance, implementation, calls, reads, writes; test-to-production relationships; configuration and build targets.

Android: Gradle modules, plugins, dependencies, variants, namespaces, application IDs; AndroidManifest components and permissions; Activities, Fragments, Compose routes and screens, XML layouts, ViewModels; repositories, use cases, data sources, Retrofit APIs, DTOs, mappers; Room databases, entities, DAOs, migrations; Services, Workers, receivers, content providers; Hilt/Dagger/Koin; Navigation Component and Compose navigation; unit and instrumentation tests.

Flutter: packages and dependencies from pubspec.yaml; widgets, screens and routes; Provider, Riverpod, BLoC and GetX state relationships; repositories, services, API clients, models and serializers; local storage and databases; platform channels matched to their native Android handlers; unit, widget and integration tests.

The model

Node types: Project, Module, Package, File, Class, Interface, Function, Method, Screen, Route, ViewModel, StateUnit, Repository, UseCase, ApiEndpoint, Dto, DomainModel, Database, Entity, Dao, Worker, Service, Test, Resource.

Edge types: CONTAINS, DEFINES, IMPORTS, REFERENCES, CALLS, INHERITS, IMPLEMENTS, INJECTS, NAVIGATES_TO, OBSERVES, EMITS, READS, WRITES, SERIALIZES, MAPS_TO, REQUESTS, RETURNS, PERSISTS, TESTS, CONFIGURES, DEPENDS_ON.

Every node and edge stores: source file, line range, extraction method (parsed | detector | resolved | inferred), confidence score, index version, source hash, and optional evidence text.

How it is built

Detect → Parse → Extract symbols → Infer roles → Create edges → Store and summarise

1. Deterministic extraction first. File and folder rules; Gradle, Manifest and pubspec parsing; tree-sitter syntax trees for Kotlin, Java, Dart, XML and Gradle scripts; framework detectors.
2. Semantic enrichment second. Architecture roles, DTO → mapper → domain chains, screen → state → use case → repository paths, component summaries, flagged uncertainty.

An LLM is used for enrichment and explanation only. Anything it produces is stored as inferred with a confidence score — never as an observed fact.

It stays current

The file watcher hashes changed files, reparses only those, removes their nodes and edges, re-resolves affected references and refreshes only the affected summaries. No full rebuild.

Large repositories

Above a threshold the graph opens at module level — one card per module with node counts and aggregated edges — and expands on demand. There is deliberately no "show everything" action for a large project; search, trace, impact and expansion are how you reach any node.

What the user sees

Architecture summary card · feature-path explorer · dependency view · impact view · "Why is this connected?" (shows the evidence rows) · Open definition · stale indicator with Refresh/Rebuild · natural-language search.

6. Appvecta Impact

Before an edit, Appvecta answers what it touches. For "Add passengerType to Ticket":

Direct model impact        TicketDto, Ticket, TicketMapper
Persistence impact         TicketEntity, TicketDao, Room migration likely required
UI/state impact            TicketViewModel, TicketScreen
Background/output impact   TicketSyncWorker, TicketPrinter
Tests likely affected      TicketMapperTest, TicketRepositoryTest, TicketViewModelTest

Observed relationships are shown separately from AI-inferred risks.

7. Appvecta Agent

Provider-neutral

The subscription rule. Appvecta uses an existing subscription only through the provider's own officially supported login or CLI. It never scrapes browser cookies, copies website session tokens, imitates private consumer endpoints, or asks you to paste browser credentials.

MCP: use Appvecta from the agent you already use

The engine runs a local MCP server exposing the Brain as tools — brain.search, brain.definition, brain.callers, brain.dependencies, brain.featurePath, brain.impact, brain.contextPack. Any MCP-capable tool (Claude Code, Codex, Cursor and others) uses them with your own account, outside Appvecta. These work with no AI provider configured in Appvecta at all.

How a request becomes context

Classify the intent → query the Brain → retrieve direct symbols plus one or two relationship levels → add relevant config and tests → include exact source ranges, not whole folders → state what is missing or low-confidence → let the agent ask for more → log every file and graph fact supplied.

Every context pack records the tokens sent and a baseline (the whole files a naive agent would have read). The UI shows the difference.

Plan, approve, apply, revert

Before anything is written the plan shows: goal · planned files · direct and indirect impact · database, API and build risks · tests to add or run · commands requested.

After the change: the diff · build and test results · QA evidence · unresolved warnings · "Revert this task", which restores only that task's hunks and leaves your unrelated edits intact.

Agent tools, all typed and allowlisted: searchFiles, readRange, queryBrain, requestSubgraph, proposePatch, applyPatch (approval), gitDiff, runCommand (category-gated), readCommandResult, requestQaPlan, launchQa (approval), readReport, replayFlow.

8. Build, Run and Device Hub

Toolbar: [ ▶ Run ] [ 🧪 QA ] [ 🧠 Brain ] [ Device: Android_API_36 ▾ ]

Android Run: detect the Gradle wrapper and SDK → detect app modules, variants, application IDs and launcher activities (by parsing, not by running Gradle) → ask once when ambiguous → save the target → build the variant → select a device or start an AVD → install the APK → launch → attach filtered logcat → show status and errors with file and line.

Flutter Run: detect the Flutter SDK → discover Android devices → detect flavors and entry points → build and install → capture structured output and device logs. Hot reload is a later enhancement, deliberately not a QA dependency.

Run state machine: Idle → Preparing → Building → Installing → Launching → Running → Stopped | Failed | Cancelled. Cancel at any state kills the child process tree.

Device Hub: list devices and AVDs with serial, model, API level, state and connection type · select the active target · start/stop an AVD · install/uninstall the debug app · launch, force-stop, clear app data (with confirmation) · screenshot · screen recording · filtered logs · current foreground activity · permissions and device state · USB and ADB-wireless.

Error classification: missing SDK, wrong JDK, Gradle sync failure, no device, install failure (signature mismatch), launch failure (missing activity) — each with an actionable message.

9. Appvecta QA

Three modes

1. Your existing tests. Android local unit tests, instrumentation and UI tests, Flutter unit, widget and integration tests — discovered and published in the editor's native Testing UI, grouped module → class → method with output, durations and failure locations.
2. Guided feature QA. Pick a feature from the Brain or describe a flow ("test login with invalid credentials then a valid account"). Appvecta proposes a deterministic plan using the selectors that actually exist in your source. You review, edit and approve.
3. Recorded flows. Perform a flow once, Appvecta records it as a reusable, editable flow. Planned for release 0.2.

Free-form exploratory QA is deliberately not a first-release commitment — deterministic execution must be reliable first.

Selector strategy

Preference order: explicit test ID / key / resource ID → accessibility identifier or content description → semantic role plus stable label → visible text → relative hierarchy → coordinates (last resort). Fragile selectors are flagged in the report.

Opt-in testability contract (documented, never required): stable resource IDs on Android Views; meaningful test tags and content descriptions in Compose; stable Keys and semantics labels in Flutter; predictable debug-only test data; a safe way to reset local state; no production credentials in test plans.

What every step records

Flow and step ID · human-readable intent · action performed · selector and fallback used · start and end time · pre/post screenshot · UI hierarchy excerpt · assertion and result · app and process state · the relevant log window · network state metadata · failure reason and confidence · retry count.

Failure classification

Assertion failure · app crash or ANR · build/install/launch failure · missing element · timeout · permission or system dialog · environment or test-data problem · automation-driver problem · suspected visual issue · inconclusive.

Not every failure is an app bug, and the report says which kind it is.

Reports

• Summary: project, commit, dirty-worktree status, framework, variant, application ID, device and Android version, start time, duration, passed/failed/blocked/skipped.
• Timeline: every action and assertion.
• Failures: expected vs actual, screenshot and optional recording, relevant logs and stack trace, the source components the Brain suggests are involved, classification and confidence.
• Actions: Replay · Open related code · Ask the Agent to investigate · Export Markdown/JSON.

Reports are JSON at the source, rendered as Markdown and as a self-contained HTML file.

Replay

Replay re-runs the exact stored flow against a declared initial state: app-data reset, account and test data, network assumption, orientation, locale, required permissions, device awake and unlocked. If a precondition cannot be re-established, the replay is labelled best effort.

A step that only passes on retry is marked flaky, not passed, and appears in the summary.

The repair loop

Failure → classified report with evidence → "Open related code" ranks source locations via an impact query → "Ask the Agent to investigate" builds context from the report, the failing step's evidence and the Brain subgraph → the agent proposes a repair → you approve → rebuild → replay → the new report links to the previous one. All three approvals are explicit.

10. Security, privacy and safety

Local by default

The graph, QA plans, runs, evidence and reports live in a .appvecta/ folder in the workspace. There is no Appvecta server in the first release. config.json and deliberately authored QA flows are safe to commit; caches, the graph database, evidence and reports are git-ignored by default. Secrets never go in files — they use the OS credential store.

Indexing never executes repository code

Building the Brain reads files. It never runs Gradle, Flutter or a project script. Only Run, Build and Test execute build logic, and the interface says so first. This is enforced by an automated test that asserts zero build executions during indexing.

Command categories

Execution rules, enforced in code

Arguments are arrays and never a shell string built from model output. Working directories are scoped to the workspace. The child environment is an allowlist. Every execution has a timeout and a cancellation token that kills the process tree. Everything is written to an audit trail with category, arguments (redacted), exit code, duration, touched files and initiator.

Secrets

Provider keys and test credentials use the editor's SecretStorage (your OS keychain). Blocked by default: .env*, *.jks, *.keystore, *.p12, *.pem, local.properties, key.properties, secrets*.xml. A redaction pipeline covers agent context, logs, audit entries, reports and diagnostic bundles. QA steps can be marked sensitive to skip screenshots.

Untrusted repositories

Repository text — code, comments, README, build scripts, QA plans found in the repo — is treated as data, never as instructions. The tool allowlist does not depend on what a model or a repository asks for. A hostile test fixture with prompt-injection comments and a malicious Gradle task is part of the test suite.

Change safety

Multi-file edits require approval. Patches are validated for path boundary, secret-file blocklist, binary content and conflicts before being applied. Every task has a checkpoint. Appvecta never runs git reset, git checkout -- ., git clean or stash operations — the only Git commands available to the agent are diff, status, log and show.

Privacy

The provider setup screen shows exactly what leaves the machine: source ranges, Brain facts, report excerpts, device metadata. Per-provider exclusion rules are supported. A "Preview context" action shows the actual payload before sending. The alpha ships with no telemetry and no crash reporting. Diagnostic bundles are user-initiated, redacted, and previewed before export.

11. Benefits

For the individual developer

For a small team or agency

For an engineering manager (Team edition, post-alpha)

12. Quality targets

All targets are engineering thresholds verified against six reference projects plus two real projects — not promises for every public repository.

Already measured (Phase 0 spike, 17–18 September 2026)

• Extension ↔ engine JSON-RPC handshake, verified in CI.
• Project detection: Android and Flutter at 0.95 confidence; unsupported on an empty folder — with no Gradle or Flutter execution.
• Device discovery: a physical Android device over USB (Android 10, API 29, armeabi-v7a) plus a stopped AVD.
• A real QA run: an 8-step login flow, 8/8 passed, a screenshot per step, 53.6 s, on that device.
• The branded IDE shell builds, launches, and reports Appvecta in Help → About.
• 176 automated tests green across 29 files.

13. Release plan

The MVP (private alpha, January 2027 target)

Private alpha invitations: the week of 11 January 2027.

Definition of MVP complete

• Android Kotlin, Java and mixed projects detected, indexed, built and run.
• Flutter projects detected, indexed, built and run on Android.
• The Brain explains representative UI → state → domain/data paths with source evidence.
• The graph updates incrementally after a file change.
• At least the Claude Code and Codex CLI adapters work through supported authentication.
• Multi-file changes are approved and the resulting diff inspected.
• Existing native and Flutter tests appear in the editor's testing experience.
• A deterministic QA plan runs on both an Android-native and a Flutter-on-Android project.
• A failed flow produces a complete evidence report.
• Replay reproduces a controlled failure from a declared initial state.
• The agent can take report plus graph context, propose a fix, rebuild and replay after approval.
• Secrets, unsafe commands, untrusted repository content and dirty working trees have documented protections.
• Installation, prerequisites, supported platforms and known limitations are documented honestly.

After the MVP

Release 0.2 — recorded flows; stronger Compose and Flutter semantics; network controls and mock responses; visual checkpoints; CI export; richer impact analysis; performance and startup smoke tests.

Release 0.3 — exploratory QA within approved boundaries; shared team QA plans; pull-request risk summaries; remote Android device execution; a plugin and provider SDK.

Release 1.0 candidate — a polished branded distribution; iOS support for Flutter; enterprise policy controls; encrypted team graph sync; production crash and analytics integrations.

Planned local differentiators (post-alpha, free edition)

• Impact radius before an edit — screens, QA flows and tests affected by a symbol, offered to the agent as a tool and to you as "run affected checks".
• Architecture guard — layer rules evaluated on the graph, shown as red edges, runnable in CI.
• Live trace on the map — edges that actually executed during a run light up.
• Tap on the device, jump to the code — a UI element maps to its composable or widget, view model and API.
• Crash to path to repro — a stack trace maps onto a graph path and drafts a QA flow that reproduces it.
• "What the AI will see" preview — the exact context pack, with redaction applied, before anything is sent.
• Generated onboarding tours — "How does login work?" becomes a guided walk along the traced path.
• Screen-level visual regression — baseline screenshots per screen node, with diffs.
• Release readiness check — hard-coded keys, unused permissions, missing R8 keep rules, Play policy risks.
• Multi-device QA matrix — the same flow on several connected devices, side by side.

Planned platform phases (post-alpha, paid)

14. Editions

Names are working titles. Pricing is not finalised.

Community is not a trial. Brain features never require an AI provider or an Appvecta account. Without an account, no licence server is contacted and nothing local is disabled.

15. Scope boundaries — what Appvecta will not do in the first release

• No iOS execution, simulators or Xcode management. Flutter is supported on Android first.
• No autonomous exploratory QA across every screen.
• No visual-regression baselines across many devices; no cloud device farm.
• No team collaboration server, hosted code, or hosted graph storage.
• No backend or web project intelligence.
• Not an Android Studio replacement: no Layout Inspector, no advanced profilers, no Compose Preview, no complete Gradle project modelling.
• No automatic deployment, Play Store submission or signing-key management.
• No POS-specific printer, card terminal, ECR or payment simulation (a later Globevik-specific edition).
• No silent autonomous edits.

16. Requirements

17. FAQ

Is Appvecta available now? No. It is in active development. The private alpha is targeted for January 2027.

Does my code leave my machine? Not for Brain features — indexing, the graph, search, trace and impact are entirely local. Code leaves only when you send it to an AI provider you configured, and the setup screen shows exactly what is sent. There is no Appvecta server in the first release.

Do I need an Appvecta account? No. The Community edition needs no account and no network.

Do I need an AI subscription? No. The Brain, Run, Device Hub and QA work with no AI provider at all. If you want the agent, you bring your own — an installed Claude Code or Codex CLI, an API key, or a local Ollama model.

Will it use my existing Claude or ChatGPT subscription? Only through the provider's own officially supported login or CLI. Appvecta never scrapes browser sessions or reuses subscription tokens, and does not promise that every consumer subscription can act as an API.

Does indexing run my build? No. Building the Brain reads files only. It never executes Gradle, Flutter or a project script. Only Run, Build and Test execute build logic, and the interface says so first.

Does it support iOS? Not in the first release. Flutter is supported on Android first. iOS requires macOS-only tooling, Xcode, signing and simulator control, and is a separate later milestone.

Is it a replacement for Android Studio? No. It does not provide Layout Inspector, advanced profilers, Compose Preview or full Gradle project modelling. It is an AI-native environment for understanding, changing and verifying mobile projects.

Can I use it in regular VS Code? Yes. The extension runs in stock VS Code 1.103 or newer. The branded distribution adds branding and defaults; it never becomes required.

What happens if the AI gets it wrong? Nothing is written without your approval for multi-file edits, patches are validated before they are applied, every task keeps a checkpoint, and "Revert this task" restores only that task's changes while preserving your unrelated edits.

How much will it cost? The Community edition is free. Paid edition pricing is not finalised.

18. Footer / legal notices

© 2026 Globevik. Appvecta is in development; features described here are planned and
subject to change. Android is a trademark of Google LLC. Flutter and Dart are trademarks of
Google LLC. Appvecta is not affiliated with or endorsed by Google, Microsoft, Anthropic or OpenAI.
Built on Code-OSS (MIT).