Projects

One-off chats are great for one-off questions. Anything bigger — a pentest engagement, a CTF, an incident response, a long research thread — needs persistent context. Projects keep the target, scope, stack, goals, and history in one place so you don’t re-paste the same paragraph into every new chat.

When you start a chat from inside a project, the model gets the project’s assets and notes injected as system context. You can ask “is the API endpoint vulnerable?” and it knows which API endpoint, which tech stack, which scope.

◈Assets

The things in scope. Five kinds: servers, domains, IPs, applications, services. Each one carries a label and an optional description. Assets are listed back to the model verbatim so you can use whatever terminology your engagement uses.

◈Tech stack tags

Tag the moving parts: nginx 1.25, postgres 16, k8s 1.30, php 8.2, laravel 11. Tags drive CVE matching, technique selection (e.g. PHP-specific deserialization gadgets), and recon depth.

◈Goals

What “done” looks like for this engagement. Free text. Surfaces in the dashboard so you don’t lose sight of the actual outcome you’re hired for.

◈Notes

A markdown engagement journal. Use it for credentials you collected, paths you tried, things you noticed. The model can reference the notes mid-chat — useful for “summarise what we’ve found so far.”

◈Scoped chats

Every conversation belongs to a project (or to your top-level inbox). The sidebar groups them per project so you can resume a thread weeks later without losing context.

• Create from /dashboard/projects → New project.
• Add assets and tags up front. The first chat will be much sharper if the model has the scope.
• Pin the project to your sidebar — chats started from the sidebar inherit it automatically.
• Mark archived when an engagement ends; archived projects stay readable but stop counting against active quotas.
• Deleting a project deletes its chats and assets but preserves command-run audit logs scoped under your account.

When you register an SSH server in /dashboard/servers, you can optionally attach it to a project. That makes the server show up in the @-mention picker by default inside that project’s chats — handy when an engagement uses one specific Kali jumphost or attack VM.

• summarise everything we’ve found on this target so far
• what’s the highest-impact thing left untested?
• draft a finding for the SQLi in /api/login I noted yesterday
• given the stack tags, which CVEs published in the last 30 days affect us?