Choose your tool.
Follow the evidence.

New here? Start with guided input

Each analysis tool opens in Guide me through it mode. Fill in the questions or choose the requested files, then select Analyse evidence. The result explains what was found, what to do next and what the check cannot establish.

Choose Advanced JSON / import to use existing evidence files, examples, multiple data rules or detailed inputs. Switching modes keeps the form’s current answers until you change tools or reload. Analysis results clear when inputs change so you do not mistake an old report for a new check.

For Data Integrity Sentinel, upload a CSV with column names and choose a simple rule. For Dependency Guardian, upload an npm package-lock.json; online advisory lookup requires the checkbox authorising package names and versions to be sent to OSV. ConfigGuard needs two fingerprint snapshots created with the local collector.

Building with AI

In App Guide, answer “Are you using AI to help you build?” and describe your project. Each lesson provides prompts for planning, implementing and reviewing the step. Copy or download the prompt into your chosen AI assistant. DevWorkroom does not send the brief to an AI service or run the suggested changes. Verify the lesson’s result before checking it off.

START HERE

Your first analysis in two minutes

1. Open ChangeTrace, or choose another analysis tool.
2. Select Load an example, then Analyse evidence. Examples are fictional and remain labelled as examples.
3. Read the observations and Coverage and limits. Expand the extra details where available.
4. Select Download input template when you are ready to prepare your own evidence. JSON is a structured text format: keep the field names, quotation marks and brackets.
5. Replace all example records with your own authorised evidence. Remove the top-level "example": true field only after replacing the example data. Save the file and use Choose an evidence file to import it. Editing an example directly on the page keeps its example label.
6. Select Analyse evidence again. Review the result, then Export report for a local JSON copy.

Inputs must be JSON files smaller than 2 MB. Reports and input templates are different files: a report is the output, not a reusable input template. Changing tools clears the current input and result, so export anything you need first.

01 · DESKTOP PRIVATE BETA

App Breaker

Use it to exercise software you are authorised to test and collect a report of actions, findings and screenshots.

Before you begin

You need an App Breaker desktop build and a disposable test environment. Public downloads are not open yet. The Mac candidate supports Apple Silicon; the Windows candidate is unsigned. Website testing includes Chromium. iOS Simulator needs a Mac and Xcode; Android needs Android tools and a connected target. Broader Android and native desktop acceptance is still in progress.

1. On Mac, unzip the supplied package, move App Breaker into Applications and open it. Allow the permissions required by the selected target. Follow the supplied beta instructions for Windows.
2. In Configure Break Run, give the project a name. First choose Mock pipeline under Runner mode to check report generation without operating a real target.
3. For a real test, choose the appropriate runner and target. For a website, enter its URL, select Generate backend challenge, serve the displayed exact marker at the displayed route, then select Verify live backend control. You need access to that website’s deployment. Verification is tied to its origin and expires.
4. Choose the test area, modules and a short initial duration. Use test accounts and disposable data: actions can change data inside the target.
5. Confirm your authorisation and select Start authorised test. Watch Live Session; use Stop safely when needed.
6. After the run ends, select Open Break Report. Review the screenshots and action history behind each finding; use JSON if you need the structured report.

What to do with the result

Reproduce important findings in the same test environment before deciding on a fix. A mock run validates the reporting pipeline; it does not test your application. A completed real run describes only the actions it observed and does not certify security or release readiness. App Breaker does not repair your code.

Reports stay on your computer, under Application Support/App Breaker on Mac or Local AppData/App Breaker on Windows. Review screenshots and target data before sharing. Local evaluation is available without an account during this beta; paid subscriptions and the proposed trial are not active.

02 · PLANNING WORKSPACE

App Guide

Use it to turn an idea into a written plan with requirements, decisions and milestones.

1. Select New project. Enter a project name, what you are building, who it is for and what success means.
2. Add requirements that can be checked. For example: “A signed-out visitor cannot open a private project.” Select Add requirement after writing each one.
3. Record each decision and its reason, then select Add decision.
4. Add concrete milestones. Mark work complete only after checking the result, and review the launch checklist against your own product’s needs.
5. Sign in with your App Breaker account and select Save project. Confirm the saved status before closing. Saving is explicit, not automatic.
6. Use Export JSON for a structured copy or Export brief for a readable Markdown document. Drafts can be exported without signing in.

Saved projects appear in Your projects. Use Reload projects to refresh the list. If another session changed a project, export your local draft before reloading, then reconcile the changes and save again.

03 · INCIDENT INVESTIGATION

ChangeTrace

Use it when something failed and you want to compare changes around the first symptom.

1. Record the first symptom’s timestamp, service and environment in incident. Use timestamps with a timezone, such as 2026-09-22T10:00:00Z.
2. Add events with unique id, at, service, environment, kind and summary. List explicitly related services in dependencies. The default look-back window is 24 hours; optional windowHours supports up to 168 hours.
3. Import the file and analyse it. Expand candidates and timeline.
4. Read both supporting and opposing evidence. Verify promising candidates against actual deployment and incident records.

Collect a GitHub timeline

Download the GitHub collector. It requires Python 3.10 or later and the GitHub CLI signed in to an account that can read your repository. Run this in the folder containing the downloaded script, replacing the repository, time and service:

python3 github_timeline.py --repo OWNER/REPO --incident-at 2026-09-22T10:00:00Z --service YOUR_SERVICE --environment repository --output changes.json

Import changes.json. Collection covers at most the latest 100 commits and 100 workflow runs. Commits are tagged repository; workflow runs are tagged ci. Add verified deployment/configuration events with their real environment for a production incident.

04 · PACKAGE REVIEW

Dependency Guardian

Use it to match exact npm package versions with collected vulnerability advisories.

1. Download the npm collector. You need Node 20 or later and a version 2 or 3 package-lock.json.
2. Place the script beside your lockfile, or provide the lockfile’s full path. Run the command below to collect versions and query OSV.
3. Import inventory.json, select Analyse evidence and review each package’s result and lookup time.
4. Follow the advisory links to assess applicability. Check an upgrade in your own test environment before changing production.

node npm_inventory.mjs package-lock.json inventory.json --query-osv

--query-osv sends package names and exact versions to OSV, not source code. Omit it to collect inventory without network lookups; those checks will remain unknown.

05 · CONFIGURATION DRIFT

ConfigGuard

Use it to find added, removed or changed configuration entries without importing their values.

1. Download the configuration collector. It requires Python 3.10 or later. Prepare local JSON objects mapping configuration names to their values.
2. Create a baseline fingerprint file and private key using the first command below.
3. Collect the current configuration using the same key and environment with the second command.
4. Combine the complete contents of the two generated snapshot files into an object with baseline and current fields, as shown below.
5. Import that combined file and analyse it. Review each changed entry against the intended configuration.

python3 config_snapshot.py --input baseline-config.json --key private-fingerprint.key --create-key --environment staging --output baseline.json
python3 config_snapshot.py --input current-config.json --key private-fingerprint.key --environment staging --output current.json

Combined file structure (replace the explanatory placeholders with the snapshot objects):

{
  "baseline": { ...contents of baseline.json... },
  "current": { ...contents of current.json... }
}

The placeholders above are not valid JSON. Paste each full snapshot object, including its environment, key ID and entries.

06 · DATA RULES

Data Integrity Sentinel

Use it to check a reviewed data export against rules you define.

1. Download the input template. Replace tables with your exported table names and arrays of rows. Remove fields you do not need.
2. Set rules for the constraints you want checked. Each rule needs type, table and field.
3. Import and analyse. Match reported row numbers to the exact imported snapshot, starting at row 1.
4. Investigate violations in your source system. Any repair is a separate, deliberate action.

required

Flags missing, null and empty-string values.

unique

Flags repeated nonempty values after their first occurrence.

reference

Checks values against targetTable and targetField. Number 1 and string "1" are different.

range

Checks numeric values against min, max, or both.

Example rule: {"type":"range","table":"orders","field":"total","min":0}.

07 · RELEASE HEALTH

Release Guardian

Use it to compare failure counts before and after a release.

1. Download the input template. Enter a release identifier and two windows: baseline and current.
2. Use the same environment and comparable traffic. Each window needs timezone-aware start and end; baseline must finish before or when current begins.
3. For each metric, supply matching name, total observations in total and failed observations in failures. Use whole numbers; failures cannot exceed total.
4. Analyse and review the before/after rates and the change in percentage points.

For example, 5 failures from 1,000 observations versus 100 from 1,000 changes the observed failure rate from 0.5% to 10%. This is an illustrative example, not a measured incident.

The screen reports unknown when either sample has fewer than 100 observations or a matching metric is absent. A warning requires an increase of at least one percentage point by default and non-overlapping approximate 95% intervals. Optional minimumIncreasePoints changes the increase threshold.

Collect observed release counts

The local runner can aggregate authorised JSONL request observations. Each record identifies its release, environment, metric, timestamp, unique observation ID and whether it failed. Choose separate baseline/current releases and fixed time windows in the runner’s documented configuration. Only aggregate counts are exported; repeated IDs are deduplicated and conflicting duplicates stop collection.

Follow the Release Guardian: refresh local request telemetry section in runtime/README.txt. Start with --once and review the results before using --watch. Missing windows remain unknown. The collector cannot establish complete delivery or prove that a release caused a change.

08 · REPRODUCTION PACKAGE

Bug Capsule

Use it to give another developer a clear, reviewed description of a reproducible problem.

1. Download the input template. Add a short title and the environment: platform, os, appVersion, browser and/or build.
2. Write ordered steps, starting from a known state. Explain expected and actual behaviour. Add relevant text lines in optional logs.
3. Analyse and expand Review the filtered capsule.
4. Read every field for private information. Edit the original input and analyse again if anything should be removed.
5. Export the report. Its capsule field contains the filtered reproduction package. Share only after your review.

Reopen an exported capsule

1. Select Bug Capsule and choose your previously exported capsule-report.json. A standalone bug-capsule version 1 object is also supported.
2. Select Analyse evidence. The tool validates the version and numbered steps, then filters the content again. Unknown formats and broken step sequences are rejected.
3. Expand Review the filtered capsule and check the steps, environment and logs. Export a fresh report only after reviewing it. Importing never runs the steps or visits the target application.

09 · MOBILE SUBMISSION REVIEW

StoreShield

Use it for a limited review of supplied iOS or Android submission metadata.

1. Download the input template. Set platform to ios or android. Supply identifier, version and build as strings from the actual package.
2. Add privacyPolicyUrl. Set createsAccounts and accountDeletion to true or false based on actual app behaviour.
3. For iOS, supply permissions with each permission’s name and user-facing purpose. For Android, use the resulting reminders to review Data Safety and target API requirements manually.
4. Analyse, follow the report’s official platform links and check the actual build and submission forms. Resolve warnings and record manual review decisions separately.

Read an iOS app’s metadata

Download the iOS metadata collector. With Python 3.10 or later, run:

python3 ios_metadata.py /path/to/Your.app metadata.json

Use an extracted iOS .app bundle, not a macOS app or an IPA archive. The collector reads Info.plist without executing the app. Add the privacy-policy URL and account behaviour manually before importing the file.

LOCAL OPERATION

Repeat checks and keep a history

Download the local runner and unzip it. You need Node.js 20 or later. Keep the runtime and collectors folders together, open a terminal in runtime, and follow its README to create a configuration file specifying your tool, evidence input, output folder and check interval.

node monitor.mjs configuration.json --once
node monitor.mjs configuration.json --watch

Use the first command for a single pass; use the second to repeat until Ctrl+C. Inputs must be outside the output folder. Each check creates latest.json and retains changed results according to your chosen retention. Errors replace previous success, and a file-age limit can flag evidence that has not been refreshed.

This runner can refresh GitHub timelines, explicitly selected SQLite data, npm inventories, configuration fingerprints and local release observations before analysis. GitHub needs Python 3 and an authorised gh login; SQLite needs Python 3. OSV queries require explicit permission to send package names and versions and an interval of at least one hour. Other evidence must be refreshed separately. The runner does not run in the cloud or continue while your computer is asleep. There are no email or chat notifications. File modification time cannot establish whether the evidence itself is current. Read the limits before relying on a report.

Automatic configuration comparisons

ConfigGuard can now refresh a local configuration comparison on every check. First create a fingerprint baseline using the ConfigGuard collector above. In the runner configuration, set product to config, choose a separate input evidence file and add:

"collector": {
  "type": "config",
  "configuration": "./configuration.json",
  "keyFile": "./fingerprint.key",
  "baseline": "./baseline.json",
  "environment": "staging"
}

Paths are relative to your runner configuration. Use the same key and environment as the baseline. Each cycle reads the current configuration, writes only names and fingerprints to evidence, and reports changes. It never uploads or modifies the configuration, key or baseline. A failed refresh records an error and preserves old evidence. Keep all source files outside the report folder. To accept an intentional change, explicitly create and review a new baseline, update the runner configuration and restart. Entry names appear in reports; never put secrets in names.

Read-only SQLite data collection

Download the SQLite collector. Prepare a selection file containing table names, explicit column lists and Data Integrity Sentinel rules. See collector instructions and example.

python3 sqlite_snapshot.py app.sqlite selection.json data.json

The collector opens the database read-only and uses a consistent transaction. It accepts ordinary tables only, rejects arbitrary SQL, and fails instead of truncating beyond 10,000 rows or 2 MB. Review selected values for private data before importing. Other database engines are not connected by this collector.

KEEP YOUR WORK

Saving, accounts and privacy

For the seven analysis tools, analysis runs locally in your browser. No account is needed to analyse or export. Input is not automatically uploaded or saved, and unsaved work can be lost on navigation or reload.

1. Review the displayed report, including its expanded details.
2. In Your report library, sign in with your App Breaker account and enter a report title.
3. Tick I have reviewed this report and want to save it to my account, then select Save report.
4. Use Load saved reports to list your reports, Open to read one or Delete to remove it. Export a copy first if you need to keep it.

Saving uploads the report and title, not the raw input file. A report may still contain summaries, names, URLs, timestamps or filtered logs derived from that input. Saved reports are snapshots; analyse and save again to create an updated report.

App Guide saves its project content online when you select Save project. App Breaker desktop reports remain local. Website sign-in sessions clear on reload; sign in again to access your saved work. Account creation is on the account page; email confirmation and recovery are still being prepared for public launch.

WHEN SOMETHING DOESN’T WORK

Troubleshooting

Back to the beginning ↑