Author an audit methodology

Each project has separate Security and Bugs methodology histories. You pick a profile, then author a version. Versions are immutable. Models are enabled project-wide, not per profile.

You need admin or owner. New Cloud projects already ship a starter methodology, so you only do this when you want your own coverage.

The matrix

Work is buckets × passes × enabled models.

• A bucket is a review area (authentication, data integrity).
• A pass is a perspective with a path scope (HTTP surface, persistence).
• A category is an optional label a bucket can include.

Start with two or three buckets and two focused passes. A bigger matrix means more model calls, often with the same evidence twice.

Author a version

1. Open the project, pick Security or Bugs, then Config.
2. Author new version.
3. Replace config_json with something like:

{
  "name": "Web API review",
  "buckets": [
    {
      "code": "auth",
      "name": "Authentication and authorization",
      "description": "Identity, session, and permission boundaries",
      "categories": ["authn", "authz"]
    },
    {
      "code": "data",
      "name": "Data integrity",
      "description": "Validation and persistence",
      "categories": ["validation"]
    }
  ],
  "categories": [
    { "code": "authn", "name": "Authentication" },
    { "code": "authz", "name": "Authorization" },
    { "code": "validation", "name": "Input validation" }
  ],
  "passes": [
    {
      "code": "http",
      "name": "HTTP surface",
      "description": "Trace untrusted requests through auth and validation",
      "scope": "src/http src/routes"
    },
    {
      "code": "storage",
      "name": "Persistence",
      "description": "Queries, transactions, tenant boundaries",
      "scope": "src/db migrations/**/*.sql"
    }
  ]
}

Every bucket and pass needs a code and name. Every pass needs a scope. Category codes a bucket lists must exist in categories.

Scopes

A scope is a space-separated list of paths or globs.

• src/http matches files under src/http/.
• * matches across /, so src/*.ts also matches src/sub/app.ts.

Incremental campaigns only run passes whose scope hits a changed path. Changes to lockfiles, Dockerfiles, .env*, and similar expand to every pass.

Prompt sections

{
  "global.md": "Audit only the bucket and pass in this slice. Report concrete, evidence-backed defects with exact file paths.",
  "severity_rubric.md": "Rate security findings as critical, high, medium, low, or info. In bug mode, interpret the same values as impact.",
  "output_schema.md": "Emit a JSON array between <THESPIDER_FINDINGS_JSON> and </THESPIDER_FINDINGS_JSON>."
}

Keep that marker in sync with the project's prompt marker. The server stitches these into every slice prompt.

Check it

1. Create version. Confirm the Config page shows it.
2. Settings: enable at least one model.
3. Bounded run:

thespider-agent run --profile security --once --max-slices 1

Open Slices. If the runner produced output but no reports, see troubleshooting.

A campaign stays pinned to the version it started with. Findings and triage stay project-global. Cadence: campaign cadence.