reis-mobile 1.0.0 → 1.0.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -5,14 +5,14 @@
5
5
  },
6
6
  "metadata": {
7
7
  "description": "AI agents for mobile engineering",
8
- "version": "1.0.0"
8
+ "version": "1.0.1"
9
9
  },
10
10
  "plugins": [
11
11
  {
12
12
  "name": "reis-mobile",
13
13
  "source": "./",
14
14
  "description": "AI agents, skills and workflows for Flutter, Android, iOS and React Native development.",
15
- "version": "1.0.0",
15
+ "version": "1.0.1",
16
16
  "author": {
17
17
  "name": "Warleson Reis"
18
18
  },
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "reis-mobile",
3
- "version": "1.0.0",
3
+ "version": "1.0.1",
4
4
  "description": "AI agents, skills and workflows for Flutter, Android, iOS and React Native development. Use /reis-mobile:doctor, /reis-mobile:review and /reis-mobile:test.",
5
5
  "author": {
6
6
  "name": "Warleson Reis"
package/CHANGELOG.md CHANGED
@@ -4,6 +4,13 @@ Format based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/). The pr
4
4
 
5
5
  ## [Unreleased]
6
6
 
7
+ ## [1.0.1] - 2026-11-11
8
+
9
+ ### Fixed
10
+
11
+ - Review instructions now prioritize applicable analyzer, linter and test results, separate confirmed tool diagnostics from additional findings, and disclose missing checks. Recurring defects with precise conditions should become regression tests or lint rules.
12
+ - README positioning now explains how AI review complements deterministic checks, replaces the lint-covered opening example, and distinguishes illustrative investigation targets from demonstrated detections.
13
+
7
14
  ## [1.0.0] - 2026-11-04
8
15
 
9
16
  ### Added
package/README.md CHANGED
@@ -1,9 +1,17 @@
1
1
  # 📱 reis-mobile
2
2
 
3
- A mobile app is not a generic project. A code review that does not know about `BuildContext` after `await`, `android:exported`, `NSAllowsArbitraryLoads` or `Podfile.lock` lets through exactly the bugs that only show up on the device. **reis-mobile** detects your project's stack, picks the right specialist and loads only the skills that apply to Flutter, Android, iOS, React Native or Kotlin Multiplatform.
3
+ **reis-mobile** gives AI assistants mobile-specific context and workflows for code review, debugging, tests and architecture. It detects your project's stack, picks the right specialist and loads only the skills that apply to Flutter, Android, iOS, React Native or Kotlin Multiplatform.
4
4
 
5
5
  **AI agents and skills for mobile development — Flutter, Android, iOS, React Native and Kotlin Multiplatform.** A plugin for Claude Code and Codex with specialist agents and skills for code review, debugging, tests, architecture, security and Firebase.
6
6
 
7
+ ### How review fits with linters and tests
8
+
9
+ Use configured analyzers, linters and tests first. For example, Dart's [`use_build_context_synchronously`](https://dart.dev/tools/linter-rules/use_build_context_synchronously) checks `BuildContext` use across asynchronous gaps; detecting that pattern is not a reason to spend tokens on a review.
10
+
11
+ The review instructions ask the assistant to reuse available check results, distinguish tool diagnostics from additional findings, and trace behavior across files and lifecycle transitions. Investigation targets include a pending request repopulating user data after logout, an older search response replacing newer results, or retries conflicting with an API's idempotency contract. These are illustrative targets, not demonstrated detections or guarantees: each finding needs a concrete trigger and code evidence. The CLI gathers context; it does not automatically run the app's analyzers or tests, and missing check results must be disclosed.
12
+
13
+ When a recurring defect has a precise, enforceable condition, capture it in a regression test or lint rule. AI can help write that check. A passing analyzer does not prove an app correct, and an AI review does not replace deterministic checks. This project does not yet provide a reproducible benchmark demonstrating additional defect detection beyond those checks.
14
+
7
15
  <p align="center">
8
16
  <a href="https://github.com/wrsilva/reis-mobile/actions/workflows/ci.yml"><img src="https://github.com/wrsilva/reis-mobile/actions/workflows/ci.yml/badge.svg" alt="CI"></a>
9
17
  <img src="https://img.shields.io/npm/v/reis-mobile" alt="Latest npm version">
@@ -46,20 +54,12 @@ A mobile app is not a generic project. A code review that does not know about `B
46
54
  ## What's new
47
55
 
48
56
  <!-- reis-mobile:latest-release:start -->
49
- ### v1.0.0
50
-
51
- #### Added
52
-
53
- - `reis-mobile mcp`, a stdio MCP server for editors that cannot load the Claude Code plugin, such as Cursor. Seven tools (`reis_mobile_route`, `reis_mobile_review`, `reis_mobile_debug`, `reis_mobile_test`, `reis_mobile_release`, `reis_mobile_detect` and `reis_mobile_doctor`) return the same JSON as the matching `--json` command, and `reis_mobile_read_instructions` serves the agent, skill and reference files a route points to.
54
- - Both MCP eras on one process: per-request `_meta` and `server/discover` from the 2026-07-28 revision, and the `initialize` handshake from 2025-11-25 back to 2024-11-05. Validated end to end with Claude Code 2.1.267; the Cursor and Codex configurations in the README follow each client's documented format.
55
- - `--dir` on `reis-mobile mcp` sets the app directory for tool calls that pass none, so a client can pass its workspace folder.
56
- - Every MCP tool is read-only and offline. `consult` and the commands that write are not exposed, and the instruction reader resolves symlinks and serves only `agents/`, `skills/` and `docs/agent-context.md`, up to 512 KB.
57
- - iOS Keychain token storage guide in `mobile-security` (`references/ios/keychain.md`): accessibility classes and backups, biometric access control, access groups, reinstall persistence, migration out of `UserDefaults`, and a Swift token store with `OSStatus` handling. Contributed by @jay23606 in #21.
57
+ ### v1.0.1
58
58
 
59
- #### Changed
59
+ #### Fixed
60
60
 
61
- - 1.0.0 is the first stable release for Flutter, native Android, native iOS and React Native, as planned in the roadmap, and ships the MCP server previously planned for v0.11.0.
62
- - The read-only commands build their `--json` output in `core/commands/payloads.mjs`, shared by the CLI and the MCP server. The output itself is unchanged.
61
+ - Review instructions now prioritize applicable analyzer, linter and test results, separate confirmed tool diagnostics from additional findings, and disclose missing checks. Recurring defects with precise conditions should become regression tests or lint rules.
62
+ - README positioning now explains how AI review complements deterministic checks, replaces the lint-covered opening example, and distinguishes illustrative investigation targets from demonstrated detections.
63
63
 
64
64
  <!-- reis-mobile:latest-release:end -->
65
65
 
@@ -440,7 +440,7 @@ Validated end to end with Claude Code 2.1.267. The Cursor and Codex entries foll
440
440
  |---|---|---|
441
441
  | **Domain** | Generic | Flutter, Android, iOS, React Native, KMP |
442
442
  | **Project context** | You explain the stack | Deterministic detection of stack, platform and variant |
443
- | **Review** | Generic | Mobile checklists: lifecycle, `BuildContext`, MASVS, manifest, ATS |
443
+ | **Review** | General review instructions | Mobile workflows: existing check results, lifecycle and cross-file behavior, findings with code evidence |
444
444
  | **Secrets in the diff** | Sent as they are | Masked before reaching the model |
445
445
  | **Specialists** | None | 22 agents and 27 mobile skills |
446
446
  | **Context cost** | Zero | ~5,500 fixed tokens (agent and skill descriptions), no hooks |
@@ -18,6 +18,8 @@ Resolve the requested base/head or working-tree scope, including staged, unstage
18
18
 
19
19
  ## Prove a finding
20
20
 
21
+ Start with configured analyzer, linter and test results for the reviewed revision and scope. Reuse applicable results or run existing checks when available and permitted; disclose missing or stale evidence. Summarize confirmed tool diagnostics separately from additional review findings, including correctness and security diagnostics. A potentially applicable rule alone is not evidence that a defect is covered. Focus additional analysis on behavior across files, lifecycle transitions and API contracts.
22
+
21
23
  1. Read the complete changed function/type and its callers, tests and platform configuration. Identify the input, lifecycle transition or configuration that activates the suspected defect.
22
24
  2. Trace the consequence across the changed boundary: lost data, crash, stale state, permission failure, exposed secret or broken platform behavior. For async changes, identify who owns and cancels the work and whether a late result can still reach the UI.
23
25
  3. Compare with the base behavior and surrounding conventions. Separate newly introduced regressions from pre-existing issues, and check whether a wrapper, validation layer or existing test already handles the case.
@@ -41,6 +41,8 @@ Read with the Read tool, in this order:
41
41
 
42
42
  Follow the agent's process, applying the skills' checklists:
43
43
 
44
+ - First inspect available analyzer, linter and test results for this revision and scope. Run existing checks only when available and permitted; otherwise state what was not checked. The CLI gathers context and does not execute these checks automatically. Summarize confirmed tool diagnostics separately from additional review findings.
45
+
44
46
  - **working-tree / range:** review the changed files. Read the full file when the diff does not give enough context. `untracked` files do not appear in the diff: read them directly. If the diff was truncated, read the remaining files.
45
47
  - **project:** there are no changes; audit the project starting from the entry points and the data layer.
46
48
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "reis-mobile",
3
- "version": "1.0.0",
3
+ "version": "1.0.1",
4
4
  "description": "AI agents and skills for Flutter, Android, iOS, React Native and Kotlin Multiplatform — a Claude Code and Codex plugin and an MCP server for reviews, debugging, tests, architecture, security and Firebase.",
5
5
  "type": "module",
6
6
  "license": "MIT",
@@ -32,7 +32,9 @@ In a cross-platform app, native code in `android/`, `ios/` or native modules get
32
32
 
33
33
  - Open the code and confirm every suspicion. A finding without evidence at `file:line` does not go in the report.
34
34
  - Do not invent APIs, versions or lint rules. Check the lock files and build files (`pubspec.lock`, version catalog, `Package.resolved`, `package.json`) before claiming something is missing, deprecated or unavailable.
35
- - Do not report style that a configured linter already enforces.
35
+ - Start with the project's configured analyzers, linters and relevant tests. Reuse results that match the reviewed revision and scope; run existing checks when available and permitted. If results are unavailable, stale or checks cannot run, disclose that limitation instead of assuming they passed.
36
+ - Keep confirmed tool diagnostics (including correctness and security diagnostics, not just style) in the checks summary; do not present them again as independent AI findings. Do not suppress a concrete defect merely because a rule might cover it: verify the rule is enabled and its output applies to the reviewed code. Trace any additional consequence beyond a diagnostic before claiming added value.
37
+ - Spend review effort on concrete behavior across files, lifecycle transitions and API contracts. Require a trigger and code evidence; illustrative scenarios are not findings. When a recurring defect has a precise condition, recommend a regression test or lint rule to enforce it.
36
38
  - When the project deliberately does something differently and it is coherent, say so instead of flagging it.
37
39
 
38
40
  ## 4. What always matters, on any stack
@@ -69,3 +71,5 @@ Prioritized list. For each item: file:line, problem, why it matters, fix.
69
71
  ```
70
72
 
71
73
  Write "No findings." in a section with nothing to report.
74
+
75
+ Include checks executed or reused, their revision/scope and results, confirmed tool diagnostics, and checks not run in the Summary. Keep additional review findings separate from those diagnostics; never imply that a clean review guarantees correctness.