ArchSetu

AI writes code, ArchSetu understands it. Understand any codebase instantly, review every change before you commit, catch leaked secrets and broken deploy config, and let an AI agent that understands your code do the work - free with GitHub Copilot, or with your own OpenAI, Claude or Gemini key.

archsetu.com · Guide: run ArchSetu: Get Started Guide · What's new · Feedback · Stuck? Email coder@archsetu.com

ArchSetu is a VS Code extension that gives developers deep structural insight into their code, across JavaScript, TypeScript, Python, Java, Kotlin, Go, C#, Rust, PHP, Ruby, C/C++, Swift, and Dart. It answers the questions every developer asks when they open an unfamiliar project:

• Where does this app even start?
• If I change this function, what breaks?
• Which functions are dead and can be safely deleted?
• How healthy is this codebase overall?
• Which files are the most complex?
• Which of my risky code paths has no test coverage?

The analysis needs no internet connection, no API keys and no AI - just fast, accurate, offline analysis of your source files, whatever language they're written in. Findings for dead code, security/IaC issues, high complexity, and untested hotspots also show up inline as squiggly underlines, right where the problem is.

Before you commit, Review My Changes reads your diff - yours, Copilot's or the agent's - and shows the callers it can break in files you never opened, functions you removed that something still calls, changed code no test reaches, and new security issues.

For DevOps and cloud work, ArchSetu finds secrets that were committed and deleted (still in every clone), environment variables a fresh deploy will be missing, and Dockerfiles that run as root or bake in secrets - all free and offline.

And when you want the work done, not just understood, ArchSetu Agent takes over: an AI coding agent in the sidebar that plans, edits, writes and runs tests, and fixes what breaks. It runs on your GitHub Copilot plan with no API key, on your own key for OpenAI, Anthropic, Google Gemini, OpenRouter, xAI, Mistral, DeepSeek, Groq or Together, or on a model on your own machine.

What's new in 0.7.0

• ArchSetu Agent runs free on GitHub Copilot - no API key. If you are signed in to GitHub Copilot (the free plan works), the agent uses Copilot's models through VS Code. Pick any model with ArchSetu: Choose Agent Model or by clicking the model name in the agent panel - Copilot, a local model server (it lists what your Ollama serves), or Claude. The new Auto setting uses whichever you have set up.
• Review My Changes - a pre-commit check, offline and in seconds. For every function your diff touches: its callers in files you did not touch, whether any test reaches it, and its complexity. Plus removed or renamed functions that are still called (calls that will break) and security findings on the changed lines, rolled up into one low / medium / high verdict. Review uncommitted work or everything since main, copy the review as Markdown for your pull request, or hand it to the agent to fix. It is on the Source Control title bar, right next to Commit.
• Bring your own key - ArchSetu: Connect AI Provider: pick Anthropic, OpenAI, Google Gemini, OpenRouter, xAI, Mistral, DeepSeek, Groq, Together, a local Ollama / LM Studio, or any OpenAI-compatible server, paste your key, and choose from the models that key can actually use. The key is checked before it is saved, stored encrypted per provider, and only ever sent to that provider.
• The agent reviews its own work - a new review_changes tool, which the agent runs when it finishes editing, so it fixes the callers it would have broken before it tells you it is done.
• Scan Git History for Leaked Secrets - deleting a key does not un-leak it. This reads the history of every branch and lists each API key, token, password and private key ever committed: who added it, when, and whether it is still in the code. Values are never shown.
• Check Environment Variables - every variable your code reads (13 languages) against .env files, .env.example, Docker Compose, Kubernetes, GitHub Actions, GitLab CI, Dockerfiles and Terraform: what a fresh deploy will be missing, what only lives in a local .env, plain-text secrets in committed config, and dead config. One click adds the missing names to .env.example.
• Dockerfile checks - the Security Scan, squiggles, SARIF export and Review My Changes now cover Dockerfiles: running as root, unpinned base images, secrets in ENV/ARG, curl | sh, chmod 777, remote ADD and exposed SSH.
• Stuck? Email coder@archsetu.com. ArchSetu: Contact Support opens an email with your ArchSetu and VS Code versions already filled in, and the address is in the agent panel, the guide and every review report.

What's new in 0.6.0

• ArchSetu Agent - an AI coding agent in the sidebar that investigates, plans, edits, runs your tests and fixes what breaks, checking call graphs and change impact before it touches shared code. Runs on Claude or on your own model.
• Security Scan - secrets, injection, weak crypto and infrastructure misconfigurations in one report, exportable as SARIF for GitHub code scanning or as Markdown.
• Secret Guard - API keys, tokens, passwords, private keys and .env values are redacted before anything reaches the AI.
• Quick Fixes on every finding - Fix with ArchSetu Agent, or Suppress on this line with an archsetu-disable-next-line comment.
• A built-in guide - run ArchSetu: Get Started Guide, or press ? in the agent panel.
• archsetu.exclude - keep folders out of every scan.

Full details in the CHANGELOG, and more at archsetu.com.

Get started

Understand your code - no setup, no AI

1. Open any project in a supported language.
2. Put your cursor on a function and press Ctrl+K B (Cmd+K B on Mac) to see everything that calls it, or Ctrl+K I for the full change impact.
3. Open the Command Palette (Ctrl+Shift+P) and type ArchSetu to see every command - try Detect Entry Points and Codebase Health Dashboard on a codebase you don't know yet.

Let ArchSetu Agent do the work - AI

1. Open the agent: click the ArchSetu icon in the activity bar on the left.
2. Connect a model: click Use GitHub Copilot - free, no API key if you use Copilot (the free plan works). Or click Bring your own key for OpenAI, Claude, Gemini, OpenRouter and more (stored encrypted, never in settings), or Run a model on this machine for Ollama or LM Studio. See Setup.
3. Check the mode at the top of the panel. Start with Ask before changes: you see every diff and every command before it happens.
4. Ask for something specific, for example "Write tests for src/billing/invoice.ts and run them" or "Give me a tour of this codebase".
5. Review as it works: approve or reject each change on its card, open the full diff in VS Code's diff editor, and press Stop at any time.
6. Read the summary - the agent tells you what it changed and how it verified it. Click any path:line to jump there.

Tips for great results: name the files or behavior you mean; say how to check the work ("...and run the tests"); for a big change, use Plan (read-only) mode first, review the plan, then switch modes and say "go ahead"; select code and use Ask Agent About Selection from the right-click menu; add an AGENTS.md or ARCHSETU.md with your project's conventions.

The same steps, with clickable buttons, are in the built-in guide: ArchSetu: Get Started Guide (also the ? button in the agent panel).

ArchSetu Agent

Click the ArchSetu icon in the activity bar and tell the agent what you want: "add input validation to the signup route and test it", "find the dead code and remove what's safe", "why does this test fail?". It works the way Claude Code and Codex do - it investigates, makes a plan, edits files, runs your tests, type-checker and build, reads the failures, and keeps going until the job is done - right inside VS Code.

What makes it different is that it can use ArchSetu's analyzers as tools. Before it changes a shared function it can ask who calls it, which routes and components depend on it, and which tests cover it (find_callers, change_impact), so the callers get fixed in the same change instead of breaking in production. When it finishes editing it runs review_changes on its own diff and fixes what that finds before it reports back. It can also call entry_points, codebase_overview, find_dead_code, file_outline, security_scan and get_problems to get oriented in seconds instead of reading files one by one.

You stay in control. Every edit shows a diff (open it in VS Code's diff editor with one click) and every command shows exactly what will run. Pick a permission mode from the panel at any time:

The agent can only touch files inside your workspace, it must read a file before it edits it (and re-read it if it changed underneath), edits to open files land in the editor's undo history, and Stop halts it instantly - including a running command.

Setup

The easiest way to pick a model is ArchSetu: Choose Agent Model, or clicking the model name at the top of the agent panel. It lists everything available to you:

• GitHub Copilot - free, no API key: if you are signed in to GitHub Copilot in VS Code (the free plan works), the agent runs on Copilot's models through VS Code's Language Model API. VS Code asks you once before ArchSetu may use a model, and requests count against your Copilot plan. By default the agent picks a standard model that paid plans include without premium requests; choose another in the list. Needs VS Code 1.95 or later. Not signed in yet? Pick Set up GitHub Copilot in the model list.

• Bring your own key: run ArchSetu: Connect AI Provider (the key button on the agent panel, or Bring your own key on its setup card), pick a provider, paste your API key, and choose one of the models that key can use:

  Provider	Where to get a key
  Anthropic (Claude)	console.anthropic.com
  OpenAI	platform.openai.com/api-keys
  Google Gemini (free tier)	aistudio.google.com/app/apikey
  OpenRouter (hundreds of models, one key)	openrouter.ai/keys
  xAI (Grok), Mistral, DeepSeek, Groq, Together AI	their consoles
  Any OpenAI-compatible server (vLLM, LiteLLM, a company gateway)	your admin

  The key is checked against the provider before it is saved, stored in VS Code's encrypted secret storage - never in settings - and kept per provider: a key is only ever sent to the provider it belongs to. Switch providers any time; each keeps its own key.

• Your own model, on your machine: pick Ollama (ollama pull qwen3-coder first) or LM Studio in the same list. Your code never leaves your machine.

• With the provider on Auto (the default), the agent uses your Claude key if you added one, else your model server if you picked a model on it, else GitHub Copilot.

• If your repository has an ARCHSETU.md, AGENTS.md, CLAUDE.md or .github/copilot-instructions.md, the agent follows it.

Secret Guard

The agent reads your code, and your code may contain secrets. With Secret Guard on (the default), API keys and tokens in known formats (Anthropic, OpenAI, AWS, GitHub, Stripe, Slack, Google, npm, JWTs), private key blocks, passwords inside connection strings, and quoted high-entropy literals assigned to names like apiKey or password are replaced with [REDACTED:<kind>] before anything reaches the model. .env, .npmrc and similar files are shown with their names but every value redacted; private key files (.pem, .key, id_rsa, ...) are never read at all. The agent also cannot write a [REDACTED] marker back into a file, so it can't clobber a real secret with a placeholder.

Security

ArchSetu: Security Scan checks the whole workspace and prints one report, grouped by severity, with clickable locations:

• Code: hardcoded secrets, eval/exec/new Function, SQL built from strings, plaintext HTTP URLs and disabled TLS verification, MD5/SHA-1 and DES/RC4.
• Infrastructure: privileged or host-namespace containers, dangerous capabilities, hostPath volumes, unpinned images, wildcard RBAC (Kubernetes, Docker Compose); public S3 buckets and databases, internet-open security groups, wildcard IAM (Terraform, CloudFormation); workflow injection, write-all tokens and untrusted checkouts in GitHub Actions.

From the report you can Export SARIF (upload it with github/codeql-action/upload-sarif to see findings in GitHub code scanning), Export Markdown for a pull request, or hand everything to the agent with Fix with ArchSetu Agent. Secret values never appear in the report or its exports.

Every ArchSetu squiggle also has two Quick Fixes (Ctrl+.): Fix with ArchSetu Agent, and Suppress on this line, which inserts a comment like this above it:

// archsetu-disable-next-line hardcoded-secret -- test fixture, not a real key
const TEST_KEY = "AKIA...";

List several rules separated by commas, or none to silence every rule on that line; archsetu-disable-line <rule> at the end of a line works too. Suppressions are honored by the squiggles, the Security Scan, its exports and the agent.

To keep folders out of every scan - a legacy package in a monorepo, generated code - add globs to archsetu.exclude, e.g. ["packages/legacy/**", "**/generated/**"].

Review My Changes

AI writes code fast, and a diff never shows you what it can break. ArchSetu: Review My Changes - also the checklist button on the Source Control title bar, right next to Commit - reads your git diff and answers the questions a careful reviewer would ask, offline, in seconds:

• Who else depends on this? For every function the diff touches, the call sites in files the diff does not touch - the code nobody re-read.
• Did I break a call? Functions you removed or renamed that something still calls. Each of those calls will fail.
• Is it tested? Whether any test reaches each changed function, through the same test-reachability walk behind the Test Risk Hotspots squiggles, and how complex it is.
• Did I add a security problem? Secrets, injection, weak crypto and IaC misconfigurations on the changed lines only - not the whole repo's backlog.

  VERDICT: HIGH RISK - REVIEW BEFORE YOU COMMIT
    - 1 removed or renamed function still called in 2 places - those calls will break
    - applyDiscount changed and is called from 12 places in 5 files you did not touch
    - 3 changed functions with no test reaching them, and no test file changed

Every location in the report is clickable. On a feature branch you can review uncommitted changes or everything since main (what the pull request will show). Then:

• Copy as Markdown - a ready-made review table for the pull request description.
• Fix with ArchSetu Agent - the agent fixes the broken calls, checks the untouched callers, adds tests for risky untested functions, and re-runs the tests and the review.

Untracked files count as new, and test files are counted but never flagged. Callers are matched by name, like the rest of ArchSetu's call graph: a common name can over-report, but a real caller is never missed.

DevOps & cloud checks

Free, offline, and nothing leaves your machine.

Scan Git History for Leaked Secrets

Deleting a key from the code does not un-leak it - every commit that ever held it is still in every clone, fork and CI cache. ArchSetu: Scan Git History for Leaked Secrets reads the history of every branch (the last 2,000 commits by default - archsetu.historyScan.maxCommits) and lists each API key, token, password and private key ever committed:

  [HIGH] aws-access-key  AKIA... (20 characters)   fingerprint 3f2a91c07d1e
      Status : deleted from the code - still in git history
      Added  : 2026-01-12  commit 9c1e4f2a  by Jane Doe
               config/aws.js:12

Values are never shown - only their first characters and a fingerprint. The report says what to do: rotate the key first, then optionally purge history. Rotated it, or it is a known test key? Add the fingerprint to archsetu.historyScan.ignoreFingerprints.

Check Environment Variables

"Works on my machine" is often a missing variable. ArchSetu: Check Environment Variables compares every variable your code reads - process.env, os.getenv, System.getenv, ENV[...] and the rest, in all 13 languages, plus ${VAR} in Docker Compose and Spring config and env() in Prisma - with everything that sets one: .env files, .env.example, Docker Compose, Kubernetes manifests, ConfigMaps and Secrets, GitHub Actions, GitLab CI, Dockerfiles and Terraform. It reports:

• read by the code, set nowhere - a fresh deploy will run without them (high when the code has no default)
• only in a local .env - teammates, CI and production will not have them
• missing from .env.example - one click adds the names, with where each is read
• plain-text secrets in committed config - a password in docker-compose.yml, a token in a workflow, a real key in .env.example
• set but never read - dead config

Copy as Markdown gives you an environment variable table for your README or deploy runbook, and Fix with ArchSetu Agent wires the missing ones into your deploy config as secret references. Only names are ever read out of .env files, never values. The agent can run the same check with its env_check tool.

Dockerfile checks

The Security Scan, the squiggles, SARIF export and Review My Changes cover Dockerfiles (Dockerfile, Dockerfile.*, *.dockerfile, Containerfile): an image that runs as root, unpinned or :latest base images, secrets baked in with ENV or passed as ARG, curl | sh, chmod 777, remote ADD without a checksum, and exposed SSH. Multi-stage builds are judged on the stage that ships.

Why ArchSetu is Different

Tools like Cursor, Copilot, and Cline are built for writing code. ArchSetu is built for understanding code - and its agent writes code with that understanding.

All Commands

Open the Command Palette (Ctrl+Shift+P / Cmd+Shift+P) and type ArchSetu to see every command.

Right-click menu

Right-click anywhere in an editor and open the ArchSetu submenu for the commands you reach for most: Ask Agent About Selection, Blast Radius Analysis, Change Impact Simulator, Explain File, Show Functions, Security Scan, Review My Changes, Check Environment Variables and Scan Git History for Leaked Secrets.

Keyboard shortcuts

Both are chords, both only fire while an editor has focus, and both are rebindable from Keyboard Shortcuts (Ctrl+K Ctrl+S). Only the two cursor-driven commands are bound by default, to keep the chance of shadowing one of your own shortcuts small.

Clickable results

Reports print locations as <absolute path>:<line>:<col>, which the Output panel turns into links, so you can click any result to jump straight to that line.

Feature Explanations

1. Explain File

Command: ArchSetu: Explain File Works on: The file currently open in your editor

Gives you a one-glance summary of any file in a supported language. Useful when you open a file for the first time and want to know what you're dealing with before reading any code.

What it shows:

• File name
• Total number of lines
• Number of functions detected
• Number of classes
• Number of import / require statements
• Name and complexity score of the most complex function in the file

Example output:

╔═══════════════════════════════════════════════╗
║           ArchSetu - File Analysis            ║
╚═══════════════════════════════════════════════╝

  File          :  auth.ts
  Total Lines   :  284
  Functions     :  11
  Classes       :  1
  Imports       :  6
  Most Complex  :  validateTokenPayload()  - score 13  (High - consider splitting)

═══════════════════════════════════════════════════

When to use it:

• First time opening a file
• Code review - quickly gauge file complexity
• Onboarding to a new project

2. Show Functions (Jump)

Command: ArchSetu: Show Functions (Jump) Works on: The file currently open in your editor

Opens a searchable dropdown (VS Code QuickPick) listing every function in the file. Type any part of the function name to filter. Press Enter to jump the cursor directly to that function.

What it shows in the dropdown:

• Function icon + name
• Line number
• The actual source code line (so you can see the signature)

When to use it:

• Navigating large files with many functions
• Faster than scrolling or using Ctrl+F to search for a function name
• Works better than the built-in "Go to Symbol" for complex files

3. List Functions

Command: ArchSetu: List Functions Works on: The file currently open in your editor

Prints a table of every function in the file to the ArchSetu output panel. Unlike "Show Functions", this stays visible as a reference while you work.

What it shows for each function:

• Sequential number
• Function name
• Starting line number
• Length in lines
• Complexity score with label (Low / Med / HIGH)

Example output:

  #    Name                            Line    Length   Complexity
  ─────────────────────────────────────────────────────────────────
    1  activate                          381    14 lines   2 Low
    2  deactivate                        396     4 lines   1 Low
    3  validateUser                       45    38 lines   9 Med
    4  createToken                        84    12 lines   3 Low
    5  refreshToken                       97    61 lines  14 HIGH

When to use it:

• Getting a full inventory of what's in a file
• Identifying which functions are too long or too complex
• Audit before a refactor

4. Function Graph (This File)

Command: ArchSetu: Function Graph (This File) Works on: The file currently open in your editor

Shows a text-based tree of which functions call which other functions - within this one file. Each function is shown as a root node, with lines below it showing what it calls.

Example output:

  login()  -  line 23
  ├── validateUser()
  └── createSession()

  validateUser()  -  line 45
  ├── hashPassword()
  └── queryDatabase()

  hashPassword()  -  line 78
  └── (does not call any other function in this file)

When to use it:

• Understanding how functions relate to each other before editing
• Finding long call chains that might be simplified
• Understanding the flow of logic in a file

Note: This only shows calls within the current file. For cross-file connections, use "Cross-File Call Graph."

5. Cross-File Call Graph

Command: ArchSetu: Cross-File Call Graph Scope: Entire workspace (all supported source files)

This is ArchSetu's most powerful feature. It scans every supported source file in your project - any mix of the 12 supported languages - and maps out which files call functions defined in which other files. The result is a full picture of how your entire codebase is connected.

How it works:

1. Reads every supported source file in the workspace (skipping node_modules, build output, and other vendor directories)
2. Detects all function/method definitions across all files, using the correct parser for each file's language
3. For each function, searches all OTHER files for calls to it
4. Groups results by the file that defines the function

Example output:

📁  src/utils/auth.ts
────────────────────────────────────────────────────
  validateUser()
    → src/routes/login.ts  :  line 45
      const result = validateUser(req.body, options)
    → src/middleware/guard.ts  :  line 12
      if (!validateUser(ctx.user)) return 401

  createToken()
    → src/routes/login.ts  :  line 67
      const token = createToken(userId, expiry)

Files scanned             : 24
Files with connections    : 8
Total cross-file calls    : 31

When to use it:

• Starting on a new codebase - see the full picture in one command
• Before a major refactor - understand all dependencies
• Architecture review - spot which files are most heavily used

6. Find Dead Code

Command: ArchSetu: Find Dead Code Scope: Entire workspace (all supported source files)

Scans the entire project for functions that are defined somewhere but never called from anywhere. These are "dead" - they exist in the code but nothing uses them.

Why dead code is a problem:

• Confuses developers ("is this actually used somewhere?")
• Takes up space and adds maintenance burden
• Can mask bugs that nobody notices because the code never runs

How it works:

1. Collects every function definition across all files
2. Searches the entire codebase for calls to each function name
3. If a function has no callers (or only the definition itself), it's flagged as dead

Example output:

  Found 3 potentially dead function(s):

  📁 src/utils/helpers.ts
       ⚠  formatDate()   -   line 12
       ⚠  parseCSV()     -   line 45

  📁 src/routes/admin.ts
       ⚠  legacyLogin()  -   line 89

  Total functions found    : 47
  Live (called somewhere)  : 44
  Dead (never called)      : 3

Important: This is static analysis. It cannot detect functions called via:

• String names (e.g. obj[funcName]())
• eval()
• Dynamic require() or import()

Always review before deleting anything.

When to use it:

• Before a release - clean up leftover code
• After a big refactor - find functions that are no longer needed
• Reducing bundle size - less code = faster load

7. Blast Radius Analysis

Command: ArchSetu: Blast Radius Analysis Works on: The word under your cursor (place cursor on any function name)

"Blast radius" is the term for how much of your codebase is affected if you change one thing. Before you rename, modify, or delete a function, run this command to see exactly what will break.

How to use it:

1. Open any file that contains (or calls) the function you're about to change
2. Click on the function's name so your cursor is on it
3. Run ArchSetu: Blast Radius Analysis from the Command Palette
4. Read the full list of every file and line that calls this function

Example output (cursor was on validateUser):

╔═══════════════════════════════════════════════════╗
║         ArchSetu - Blast Radius Analysis         ║
║  Everything that depends on this function        ║
╚═══════════════════════════════════════════════════╝

  Function        :  validateUser()
  Affected files  :  3
  Total call sites:  5

  All of the following will need attention if you change this function:

  📁 src/routes/auth.ts  (2 call site(s))
      line   45 :  const ok = validateUser(req.body)
      line   89 :  if (!validateUser(token)) throw new Error(...)

  📁 src/middleware/guard.ts  (2 call site(s))
      line   12 :  validateUser(ctx.user)
      line   34 :  return validateUser(payload)

  📁 tests/auth.test.ts  (1 call site(s))
      line   23 :  expect(validateUser(mockData)).toBe(true)

When to use it:

• Before renaming a function
• Before changing a function's parameters
• Before deleting a function
• During code review to understand impact of proposed changes

NEW - Change Impact Simulator

Command: ArchSetu: Change Impact Simulator Works on: The word under your cursor (function, class, or any exported symbol)

The most comprehensive pre-change analysis in ArchSetu. Before you touch a symbol, run this to see a full interactive panel showing everything that will be affected.

How to use it:

1. Place your cursor on any function name, class name, or exported identifier
2. Run ArchSetu: Change Impact Simulator from the Command Palette
3. A panel opens beside your editor with the full impact report

What the panel shows:

Risk Score Algorithm:

Risk Levels:

Example panel (cursor was on calculateInvoice):

⚡ Change Impact Simulator

calculateInvoice()
src/billing/invoice.ts                                              [HIGH]

┌────────────┬──────────────┬──────────────┬────────────┬──────────────┐
│  17        │  8           │  4           │  2         │  3           │
│  Call Sites│  Files       │  Modules     │  API Routes│  UI Components│
└────────────┴──────────────┴──────────────┴────────────┴──────────────┘

Risk Score  84 / 100
████████████████████████████████████████████████████░░░░░░░░░░

▶ API Routes (2)
▶ Frontend Components (3)
▶ Importing Modules (4)
▶ All Call Sites (17)
▶ Recommended Tests (3)
▶ Circular Dependencies (none)

When to use it:

• Every time before you modify a function that might be shared
• When onboarding - understand the risk profile of key functions
• During architecture reviews - identify your highest-risk symbols
• Before deploying - validate test coverage for changed functions

8. Detect Entry Points

Command: ArchSetu: Detect Entry Points Scope: Entire workspace (all supported source files)

Finds every "door into your application" - the places where execution starts or where the outside world can call into your code. Grouped by type for easy reading.

Entry point types detected:

Example output:

  ── HTTP GET ─────────────────────────────────────
  /                          src/routes/index.ts  :  line 5
  /api/users                 src/routes/users.ts  :  line 8
  /api/users/:id             src/routes/users.ts  :  line 15

  ── HTTP POST ────────────────────────────────────
  /api/login                 src/routes/auth.ts   :  line 12
  /api/register              src/routes/auth.ts   :  line 34

  ── Export ───────────────────────────────────────
  validateUser               src/utils/auth.ts    :  line 45
  hashPassword               src/utils/auth.ts    :  line 67

  ── Main ─────────────────────────────────────────
  main                       src/index.ts         :  line 1

  Total entry points found: 9

When to use it:

• Day one on a new codebase - "where do I even start?"
• API documentation - see all your routes in one place
• Security review - see every public-facing entry point at a glance

Frameworks supported:

9. Codebase Health Dashboard

Command: ArchSetu: Codebase Health Dashboard Scope: Entire workspace (all supported source files)

Opens a visual panel inside VS Code showing the overall health of your codebase. Think of it like the dashboard in a car - one look tells you if something needs attention.

What the dashboard shows:

Health Score (0-100) A single number that grades your codebase:

• 70-100 (Green - Healthy): Complexity is low, code is maintainable
• 40-69 (Orange - Needs Attention): Some complex functions that should be simplified
• 0-39 (Red - Critical): High complexity throughout, refactoring is strongly recommended

The score is calculated from the average maximum complexity across all files. The lower your complexity, the higher your score.

Key Stats (top row)

• Total source file count
• Total function count
• Total lines of code
• Average complexity score

Complexity Hotspots Table The 5 files with the highest complexity. Shows:

• File path
• The single most complex function in that file
• Complexity score with warning labels

Largest Files Table The 5 files with the most lines. Files over 500 lines get a warning - they are likely doing too many things and are candidates for splitting.

Highest Coupling Table The 5 files that import the most other modules. High import counts mean the file depends on many other parts of the system, making it hard to change in isolation.

When to use it:

• Monthly code health check
• Before planning a refactoring sprint - see where to focus
• When a new developer joins - show them where the rough edges are
• After a fast-growth period to see what technical debt has accumulated

NEW - Inline Diagnostics

Command: ArchSetu: Refresh Inline Diagnostics Scope: Entire workspace - runs once on startup, again on file save, and on demand Also on: Every save (configurable) - this is the one feature that behaves like a linter instead of an on-demand report

Squiggly underlines, right in the editor and in the Problems panel, for four categories of findings. Same deterministic, local-only, no-AI analysis as every other ArchSetu feature - nothing here calls out to a network or an LLM.

1. Dead Code (Information) A function is only flagged when it's confidently dead: not exported (an exported function with zero internal callers may still be public API used outside this workspace) and not defined in a test file.

2. Security Findings (Error / Warning / Information, by severity) Hardcoded secrets (API keys, passwords, AWS keys, private key material), unsafe dynamic execution (eval/exec/new Function), string-built SQL queries, insecure transport (plaintext HTTP, disabled TLS verification), and weak cryptography (MD5/SHA-1, DES/RC4).

Plus optional Infrastructure-as-Code coverage for YAML and Terraform files:

• Container/Kubernetes: privileged containers, hostNetwork/hostPID/hostIPC, dangerous Linux capabilities, hostPath volumes, wildcard RBAC, unpinned (:latest) image tags
• Cloud exposure: security groups open to 0.0.0.0/0 (ingress only - egress-to-anywhere is normal and is never flagged), public S3 ACLs, publicly-accessible databases, wildcard IAM policies
• CI workflow injection: untrusted ${{ github.event.issue.title }}-style expressions interpolated directly into a run: step, pull_request_target combined with checking out the fork's own head ref/sha, permissions: write-all

3. High-Complexity Functions (Warning above 11, Error above 20) Same thresholds as the Health Dashboard's "11+ = hard to maintain" label. The message names the function and its complexity score.

4. Test Risk Hotspots (Warning) Complex, frequently-changed functions with no detected test coverage - the highest-probability place a bug is both introduced and missed (Adam Tornhill's "hotspot" methodology). Starting from every test file, ArchSetu walks the call graph - including calls made from inside anonymous test callbacks like test('x', () => { doThing() }), which a plain named-function call graph would miss entirely - to find what's actually exercised. Ranked by complexity × (1 + commits touching the file) when the workspace is a git repo, complexity alone otherwise. Trivial functions and dead code are excluded (dead code needs deletion, not a test).

Settings (Settings → Extensions → ArchSetu, or archsetu.diagnostics.*):

One developer-only setting lives outside that group:

Complexity Score Explained

Every function in your project gets a complexity score. Here is how to read it:

The score counts:

• if / else if statements
• for / while / do loops
• case in switch statements
• catch blocks
• && and || logical operators (short-circuit paths)
• Ternary operators ? :

Supported Languages

ArchSetu detects functions, methods, entry points, imports/exports, and complexity across 12 languages:

Each language has its own detection engine tuned to that language's syntax - named functions, methods with visibility modifiers, arrow/lambda functions, and language-specific block structure (braces, Python indentation, Ruby end keywords). JavaScript/TypeScript function detection covers:

// 1. Named function declarations
function myFunc() {}
export async function myFunc<T>(arg: T): Promise<void> {}

// 2. Arrow functions
const myFunc = () => {}
const myFunc = async (a: string, b: number) => {}
export const myFunc = (x: number) => x * 2

// 3. Function expressions
const myFunc = function() {}
const myFunc = async function() {}

// 4. Class methods
class MyClass {
  public myMethod() {}
  private async fetchData(): Promise<Data> {}
  static getInstance() {}
}

Getting Started (Development)

# Install dependencies
npm install

# Build the extension
npm run build

# Build and watch for changes automatically
npm run watch

# Type-check without building
npm run lint

Then press F5 in VS Code to launch the Extension Development Host - a new VS Code window with ArchSetu loaded.

Open any project folder in a supported language in that window, open the Command Palette (Ctrl+Shift+P), and type ArchSetu to see all commands.

Tech Stack

• TypeScript - the extension itself
• VS Code Extension API - for editor integration, output panels, webviews, and QuickPick
• ESBuild - fast bundling
• Node.js fs module - for reading workspace files
• Two bundled runtime dependencies - yaml for IaC parsing, and the official @anthropic-ai/sdk, used only by ArchSetu Agent

Performance Notes

Commands that scan the whole workspace (Cross-File Graph, Dead Code Finder, Entry Points, Health Dashboard, Change Impact Simulator) read every supported source file on disk. They show a loading spinner while working.

On small to medium projects (under ~500 files), these commands complete in 1-5 seconds. On very large projects (1000+ files), they may take 10-30 seconds.

node_modules, .d.ts files, and common per-language build/vendor directories (__pycache__, .venv, target, vendor, bin, obj, Pods, .dart_tool, dist, build, .next, coverage) are always excluded automatically.

Need help?

Stuck while using ArchSetu? Email us at coder@archsetu.com - tell us what you were trying to do and what happened instead, and we will help you out. The ArchSetu: Contact Support command opens that email with your ArchSetu and VS Code versions already filled in.

Feedback & Suggestions

Found a bug? Have an idea for a new feature? Something not working as expected?

Share your feedback here →

All feedback is read personally. Your input directly shapes what gets built next. Guides, release news and what's coming next live at archsetu.com.

Privacy

Every ArchSetu analysis - the commands, the dashboard, the inline diagnostics - is 100% local and offline.

• Zero network requests
• Zero telemetry
• Zero API keys required
• Your source code never leaves your machine

ArchSetu Agent is the one exception, and only when you use it. Nothing is sent anywhere until you configure a provider and send a message. Then the conversation - your messages, and the files, command output and analysis results the agent reads while working - goes to the model provider you chose: GitHub Copilot through VS Code, Anthropic for Claude, the provider you connected your own key for (OpenAI, Google, OpenRouter, ...), or your own server. Each API key is only ever sent to the provider it belongs to. Point it at a local server (Ollama, LM Studio, vLLM on your own machine) and the agent is fully local too. API keys live in VS Code's encrypted secret storage, never in settings files, and Secret Guard redacts secret values from everything the agent reads before it is sent.

The welcome message and the once-per-update notice are shown locally, from the extension itself - they make no network request, and archsetu.com only opens if you click it.

Architecture

ArchSetu is built as a modular Engineering Intelligence Platform:

src/
├── extension.ts          ← thin entry point (activate/deactivate only)
├── types/index.ts        ← all shared TypeScript interfaces
├── parser/               ← function detection engine (regex + brace counter)
├── analysis/             ← reusable analysis modules
│   ├── ComplexityAnalyzer.ts
│   ├── CallSiteAnalyzer.ts
│   └── ChangeImpactAnalyzer.ts
├── commands/             ← one file per VS Code command
├── agent/                ← ArchSetu Agent
│   ├── AgentRunner.ts    ← the agent loop: model turn → validate → permission → tool → repeat
│   ├── providers/        ← Claude (Anthropic SDK) and OpenAI-compatible model sessions
│   ├── tools/            ← file, command, plan and ArchSetu analysis tools
│   └── AgentController.ts← VS Code glue: settings, secrets, approvals, diff editor
├── ui/                   ← webview HTML builders + status bar + agent chat view
└── utils/                ← file I/O, text helpers, editor utilities
media/agent/              ← chat panel script, Markdown renderer and styles

Every analysis module is independently reusable by future features. No logic is duplicated across commands.