Everything you need to know about the Boot Camp portal
The guided onboarding tutorial is temporarily unavailable while we finish the documentation and demo content for each step. The User Guide below has the same material in article form.
Boot Camp is a structured way to build software with AI. The portal and the AI assistant follow the same stages so that analysis, architecture, and implementation stay aligned and traceable — with feature specs, ADRs, and a clear task-to-roadmap flow.
The methodology is split into five stages. The AI guides you through each stage and keeps documentation (specs, decisions, roadmap) in sync with the repo.
1. Boot
Project scaffolding and team setup. Infrastructure, documentation structure, and team policies are pre-configured. Azure DevOps provisioning, rules deployment, and initial docs.
2. Analyse
Understand the problem. Gather requirements, analyze the existing system, run intake and risk assessment. Use chat to refine scope and create feature specs before any code.
3. Develop
Build the solution. Follow specs, write tests, and use AI agents for coding tasks. Feature specs and ADRs are required before implementation. Kanban-based task workflow tracks progress.
4. Launch
Go-live and handover. Deployment checklist, acceptance testing, production verification, and documentation finalised. Everyone signs off together.
5. Maintain
Evolve and operate. Customer feedback, new feature requests, and market shifts feed back into Analyse — starting the next cycle. Meanwhile: dependency updates, security patches, tech debt tracking, monitoring, and compliance upkeep keep the product healthy.
New workspaces use the Getting started flow at /getting-started after sign-up (or anytime your organization still has onboarding open). You must be signed in — from the public guide, use Sign in first. Progress is saved on your customer record.
src/ when a repo is linked). Live status appears when an execution server is connected.https://github.com/org/repo.git or your Bitbucket HTTPS URL). SSH URLs are not supported in this wizard.repo scope, or a fine-grained PAT with read access to repository contents and metadata. Paste it in step 2 and run Test connection.The AI chat is your primary interface for interacting with the Boot Camp agent. It understands the project context and follows structured engineering practices.
"What architecture pattern should I use for the user authentication module?"
"Create a Task Center task for implementing the search feature"
"Review this code snippet for potential issues"
"Set up the Azure DevOps integration for this project"
Boot Camp uses two main kinds of documentation: feature specs and ADRs (Architecture Decision Records). They answer different questions.
docs/features/<name>/README.md.docs/decisions/ADR-NNN-title.md.In short: a Feature is what we build; an ADR is why we chose a particular way to build it.
Lifecycle stage vs “phase” in docs. The five methodology stages (Boot → Maintain) describe where the project is overall. Feature specs and ADRs use phases for implementation slices inside one document (e.g. spec Phase 1 / Phase 2). When you create an ADR, the Phase field records decision timing (analysis, architecture, …) — that label is not the same as the project's current lifecycle stage.
The AI assistant follows Boot Camp rules — codified guidance that keeps documentation and workflows consistent. Rules live in .cursor/rules/ in the project repo.
.cursor/rules/*.mdc..cursor/rules/project/*.mdc. Rules-push never overwrites these — they stay with the project.When adding a new rule: Default to project-specific. Create .cursor/rules/project/<topic>.mdc with source: project in the frontmatter. Only add to the flat Boot Camp rules when the rule is part of the shared methodology for all projects.
Projects
Each project has its own chat, docs, and configuration. Open a project to work with the AI or browse documentation.
AI Chat
Conversational assistant that knows Boot Camp. Ask about architecture, attach files for analysis, or request feature specs and mockups.
The backlog is the first column in the Task Center Kanban. Tasks at status BACKLOG are proposals: high-level ideas or bugs not yet committed to the delivery plan. Create a FEATURE or BUG task to capture a new idea.
The roadmap is the approved delivery plan by milestones. Items on the roadmap have been scoped (turned into a clear feature spec or bug-fix plan) and accepted by the team or stakeholder. So: Task Center Backlog = intake proposals; roadmap = committed work.
chat/* branch. The assistant creates or updates docs (feature specs, ADRs) on that branch.develop.docs/ROADMAP.md in git when the team commits to delivery.These features help stakeholders validate requirements early and get the most out of the portal during the Analyse stage.
Interactive HTML mockups
Ask the chat for a web UI mockup (e.g. "create a mockup for the login screen"). When the assistant writes an HTML file under docs/assets/mockups/, click the file path in the message — a panel opens with the mockup rendered live. Use the toolbar to open in a new tab or download.
Attach intake documents
Drag and drop requirements docs, spreadsheets, or screenshots into the chat. The assistant can summarize them and suggest feature specs or tasks.
Feature specs & open questions
Ask for "create a feature spec for [X]" or "what are the open questions for this project?" to keep analysis structured and traceable.
How rules work (and why documentation stays consistent)
The portal and the AI follow the same Boot Camp rules: codified guidance that both humans and AI use. For documentation, the rules say things like: create a feature spec before any implementation; once something is scoped and accepted, add it to docs/ROADMAP.md; record important technical decisions in docs/decisions/ (ADRs). The AI is instructed to update these docs whenever it changes behavior or completes work, so the repository stays the single source of truth. As a business owner you can rely on the Docs tab to reflect what has been agreed and what is planned — and the chat assistant will suggest or create the right documents (specs, ADRs) because the rules require it.
Every page has a help button (the ? icon) in the top area. Click it for context-specific guidance, tips, and links to related features. You can also ask the AI chat assistant any question about the platform.
Sign in to see your role highlighted below and to open admin-only quick links.
The Boot Camp portal is an AI-powered software development platform. It guides you through the full software lifecycle — from analysis and architecture to implementation and deployment — using AI agents that follow structured engineering practices.
Create a projectAdmin
Set up a new project with its type, description, and repository URL.
Connect Azure DevOps
Link the project to an Azure DevOps organization for work item and repo sync.
Start chatting
Open the project chat to discuss architecture, create tasks, or ask questions.
Boot Camp expects the AI in your IDE to follow the same rules as the project. If Cursor does not load the workspace, or you open a parent folder instead of the repository root, rules may be missing and behaviour will feel inconsistent.
.cursor/rules/ (usually the git repo root). Do not open only a subfolder such as portal/ unless that folder is the actual repo root..cursor/rules/*.mdc are applied.node bootcamp-scripts/sync-rules.mjs (updates CLAUDE.md, .claude/rules/, and portal/src/lib/boot-camp-rules.ts).Several rules in this template are always on for a normal workspace open (for example feature scoping, documentation, testing, and git workflow). They intentionally require traceability: new work is tied to feature specs and the roadmap, API and Server Action changes need tests, and user-visible changes need changelog or spec updates. That can look like “it only wants to create documents” — it is the methodology, not a misconfigured IDE.
<< Back to Boot Camp Guides | << Back to Home
Project type:
it-infraRule file:.cursor/rules/it-infra.mdcFor: IT consultants, internal IT staff, and business owners of small companies (up to 50 people) with hybrid on-premises and cloud environments Guide version: 1.0 | Last updated: 2026-05-03
IT Infrastructure Management is a Boot Camp project type that helps small companies document, track, and improve their IT environment. It produces structured documents that give the business owner a clear, readable picture of what IT assets the company has, what decisions have been made, how to recover from failures, and where the gaps are.
The project type does not build software. Instead, the AI agent acts as a documentation assistant and auditor — helping you build and maintain a living record of your infrastructure.
What it replaces:
What it produces:
| Role | How they use it |
|---|---|
| IT consultant / MSP | Boots the project during onboarding of a new client; uses the agent to build out documentation and run gap analysis; reviews and updates on each visit |
| Internal IT person | Maintains the documentation as the environment changes; uses runbooks for day-to-day tasks; uses gap analysis to justify IT investment requests |
| Business owner | Reads the summary sections to understand their IT risks; approves major IT decisions; uses the change records to track what systems the company depends on |
Note: This project type is for a single company. It does not support managing multiple clients from one project.
When you start an it-infra project, the agent conducts a discovery conversation with you. You do not need to prepare a spreadsheet or have every answer ready — the agent will ask you what it needs.
The conversation covers five areas in order:
Hardware — What physical equipment does the company have? Servers, workstations, laptops, network devices (firewall, switches, routers), printers, IoT devices (cameras, sensors, smart devices). Which of these are business-critical?
Software and licenses — What software does the company use? Operating systems, Microsoft 365 or Google Workspace, security tools (antivirus, backup software), any business applications. When do subscriptions renew?
Cloud accounts — Which cloud platforms does the company use? Azure, Microsoft 365 tenant, AWS, Google Workspace. Who is the owner or admin for each?
Business systems — What major business applications does the company depend on? CRM, accounting software, HR system, ERP, project management tools. Who is responsible for each one inside the business?
Network overview — How is the network structured? On-premises segments, cloud segments, internet connections, where the firewall sits.
After this conversation, the agent creates five foundation documents as starting drafts, pre-filled with what you told it. You review and complete them before any other work begins.
These documents live in docs/inventory/ and are the foundation for everything else. Keep them accurate — they are the source of truth for gap analysis and runbooks.
docs/inventory/HARDWARE-ASSETS.md)A table of all physical and virtual hardware. Each row is one device: its name, type, location, who it belongs to, whether it is business-critical, and when its warranty expires.
What this means for the business: This is your IT asset register. It tells you what equipment you own, what is getting old, and what would hurt the business if it failed. Without it, you cannot budget for replacements or plan what needs a recovery procedure.
Keep it current: Review quarterly. Update immediately when hardware is added, moved, or retired.
docs/inventory/SOFTWARE-ASSETS.md)A table of all software and SaaS subscriptions. Each row covers a product, its vendor, how many licences you have, when it renews, and what it costs.
What this means for the business: This is your software budget tracker. It prevents surprise renewal bills, shows you what you are paying for, and makes sure you are not running unlicensed software.
Keep it current: Check renewal dates at least 90 days before they fall due. The gap analysis will flag expiring licences for you.
docs/inventory/CLOUD-ACCOUNTS.md)A list of all cloud accounts and tenants: your Microsoft 365 tenant, Azure subscriptions, AWS accounts, and any others. Each row includes who owns the account and what it is used for.
What this means for the business: Cloud accounts are often forgotten or duplicated. This list makes sure you know what you are paying for and who is responsible. If a cloud account is compromised or needs to be transferred, you need this list.
docs/inventory/BUSINESS-SYSTEMS.md)A list of all major business applications (CRM, accounting, HR, etc.). For each system, you record who owns it in the business, who the IT contact is, and how critical it is.
What this means for the business: This is the record of what software the business depends on. Every system on this list should have a change record (see below) and — if it is critical — a recovery procedure.
docs/inventory/NETWORK-OVERVIEW.md)A one-page overview of the network: what is on-premises, what is in the cloud, how they connect, and where the firewalls are. This can be a table or a diagram.
What this means for the business: When something goes wrong with the network, or when you are planning a change, this document tells you what connects to what. Without it, troubleshooting takes much longer.
Whenever the IT environment makes a significant choice that is hard to reverse, the agent creates an IT Infrastructure Decision Record (IT ADR). These live in docs/decisions/ as ITADR-NNN-<description>.md.
Routine changes — adding a user account, changing an IP address, adding a firewall rule — do not need an IT ADR. Those are change records (see below).
Each IT ADR explains:
What this means for the business: IT ADRs protect the business from knowledge loss. When the IT consultant moves on or the system changes, this record explains why things are the way they are and how to reverse the decision if needed.
When the business decides to adopt a new software system (a CRM, an accounting package, a collaboration tool), the agent creates a Change Record. These live in docs/change-records/ as CHANGE-NNN-<description>.md.
A change record is not a project plan or implementation tracker. It documents the IT impact of the decision:
BUSINESS-SYSTEMS.md that does not yet have a change record gets oneWhat this means for the business: Change records give the business owner visibility into IT decisions without needing to understand the technical details. They answer: "why do we have this software, what does it depend on, and what happens if it goes away?"
Runbooks are step-by-step instructions for IT tasks. They live in docs/runbooks/ organised in three tiers based on risk.
docs/runbooks/tier-1/)These cover routine, recurring tasks: restarting a server, running the weekly backup check, onboarding a new employee, provisioning a device, resetting a password.
A good Tier 1 SOP means any IT-literate person can follow the procedure — it does not have to be the IT expert. This is especially important when a consultant is not on-site.
Review: Check at least once a year that the steps are still accurate.
docs/runbooks/tier-2/)These cover unexpected failures and security events: the email system is down, a ransomware alert has triggered, the VPN is not connecting, someone is reporting suspicious login activity.
Each Tier 2 runbook includes a severity level (P1 = business stopped, P2 = major impact, P3/P4 = manageable), steps to contain and resolve the problem, and a short template for who to notify and what to say.
After an incident is resolved, a brief lessons-learned note is added to the runbook: what happened, what worked, what to improve.
Review: Check at least once a year. Update after any P1 or P2 incident.
docs/runbooks/tier-3/)These cover catastrophic failures: a server is completely destroyed, ransomware has encrypted everything, the office burns down, a cloud account is compromised.
Each Tier 3 runbook defines:
Test schedule: Every Tier 3 runbook must be tested at least once a year. An untested DR plan is not a DR plan.
Every system marked as Critical in BUSINESS-SYSTEMS.md must have at minimum a Tier 1 operational SOP and a Tier 3 disaster recovery runbook. This is enforced by the gap analysis.
The gap analysis is an audit the agent runs against your existing documentation. It checks for missing or out-of-date documents and produces a list of Task Center tasks — one task per gap.
Each task includes:
missing-runbook, expiring-license, no-backup-documented)| What the agent found | What to do |
|---|---|
| Hardware inventory is missing or empty | Run discovery again; fill in HARDWARE-ASSETS.md |
| Software inventory is missing or empty | Fill in SOFTWARE-ASSETS.md |
| Cloud account list is missing or empty | Fill in CLOUD-ACCOUNTS.md |
| Business system with no change record | Ask the agent to create a change record for that system |
| Undocumented system (referenced but not in inventory) | Add it to BUSINESS-SYSTEMS.md and create a change record |
| Critical system with no runbook | Ask the agent to create a Tier 1 SOP and Tier 3 DR runbook |
| Critical system with no disaster recovery procedure | Ask the agent to create a Tier 3 DR runbook |
| Major IT decision with no IT ADR | Ask the agent to document the decision as an IT ADR |
| Runbook or IT ADR not reviewed in 12+ months | Review and update the document; update the review date |
| Software licence renewing within 90 days | Check whether to renew, change plan, or replace |
| No MFA policy documented | Create an IT ADR or change record covering MFA |
| No backup documented for any critical system | Create a backup IT ADR and a Tier 3 DR runbook |
The gap analysis references CIS Controls v8, Implementation Group 1 (IG1) — the baseline set of 56 security safeguards that every organisation should have in place, regardless of size. This is not a compliance certification; it is a directional guide to help prioritise what to fix first. If you choose to pursue a formal cybersecurity assessment or insurance requirement, this documentation gives you a strong starting point.
Documentation that is never updated becomes a liability. The following review schedule keeps the IT documentation useful and accurate.
HARDWARE-ASSETS.md: has any equipment been added, moved, or retired? Update the list.SOFTWARE-ASSETS.md: are there any new subscriptions? Any renewals coming up? Any software that is no longer used?NETWORK-OVERVIEW.md: does it still reflect the current network?Any time the environment changes significantly (new cloud platform, new firewall, new critical business system, staff change), update the relevant documents immediately — do not wait for the quarterly review.
Use the Task Center to track any update tasks generated by the gap analysis.
You do not need to understand every technical detail. Here is what matters:
Read the Business Systems inventory (BUSINESS-SYSTEMS.md) once, and make sure the criticality ratings are correct. You know which systems the business cannot function without — make sure those are marked Critical.
Review gap analysis tasks when the IT consultant or internal IT person runs them. The tasks are described in plain language. Your job is to approve priorities: which gaps are most important to fix first, based on what matters most to the business.
Ask about any IT ADR or change record you do not understand. Every one of these documents has a "What this means for the business" section. If it does not make sense, ask the IT person to explain it in plain language and update the document.
Make sure DR runbooks are tested. An untested recovery plan is the single biggest IT risk for a small company. Ask your IT consultant or IT person when the last test was run, and put the next test date in the calendar now.
Use this documentation when IT staff change. If your IT consultant or employee moves on, this documentation means the next person does not start from zero. Make sure handover always includes a review of these documents.
Portal-facing improvements, grouped by release date (day, month, year). The delivery plan and milestones live in ROADMAP.md.
Maintenance: Keep roughly the last 14 days of dated sections here—remove older ## sections when you add new ones so the User Guide tab stays readable. The portal loads this file from docs/guides/USER_GUIDE_CHANGELOG.md at runtime (monorepo layout). Agent rule: .cursor/rules/project/user-guide-whats-new.mdc (when to add bullets, trim policy).
develop waits until you click Save docs or start a new topic / create a task. Inquiry-only messages no longer trigger continuous “saving to git” sync when the project clone is already up to date.Follow-ups dashboard card — The home dashboard card is now Follow-ups (not a full task list): overdue, stale, roadmap, open questions, and workshop items with Discuss links into project chat. Email subject line matches.
Task picker in chat — Open tasks show assigned to you first, then an Unassigned pool with an agent triage button. Implementation review tasks open the task review panel instead of starting elaboration chat.
Developers — MCP docs stdio-only — User Guide → Developers, Settings → Boot Camp MCP, and Environment setup document only the local stdio proxy (@strikeforcealpha/bootcamp-mcp). Direct HTTP MCP setup steps were removed; repo sync already commits stdio config.
Projects — chat-first landing — Opening a project from the list, customer page, or activity feed now lands on planning chat instead of the overview dashboard. Use the Overview tab when you need team, token costs, or DevOps setup.
Onboarding — coach in chat — New business owners get an onboarding coach inside project chat (compact strip above the composer) instead of a floating widget covering Send on mobile. Skip for now pauses coach nudges for seven days; progress in the tutorial is kept.
Workshop — agent conductor — Guided workshops run end-to-end in planning chat: the agent asks one question at a time, captures answers to responses.md, advances slides automatically, then offers outcomes synthesis and Task Center follow-up when all questions are done.
Workshop — slides and facilitator help — The slide pane has Open full size for the room or a second monitor. Ask in planning chat how workshops work and the agent explains the split layout, one-question flow, and automatic advance in plain language.
Compliance — unified audit — Rules → Compliance runs one audit (rules, docs, feature specs) with per-project Push rules and doc-fix actions; orange stale badges clear after a successful push.
Dashboard — daily summary — Boot Camp daily summary merges follow-up counts into one card; tap the bell or header to open Activities.
Boot Discovery — project values optional — Step 1 is Project values & culture and can be skipped; the planning agent reminds you when later topics start if it stays empty.
Projects — BYOK token cost on overview — The project Token Usage widget now shows an API key cost estimate for BYOK usage (Anthropic Sonnet pricing), not only SFA platform cost. Legacy chat rows and daily rollups are included so BYOK-heavy projects no longer show $0.00 when tokens were consumed on your key.
MCP and planning chat — auto-sync develop — Boot Camp MCP tools and project planning chat now pull the latest develop into the hosted clone before task management, reading specs, and implementation dispatch (cached ~90s per project so burst calls sync once). You no longer need to run sync_repo manually before list_tasks / build_feature.
Initialize repository — reliability — Initialize repository on project Overview/Edit no longer hangs indefinitely: stale agent setup runs time out with a retry message, sync init shows progress and a clear error on failure, and git authentication uses in-process credentials on the portal host (fixes push failures and long spinners when BC-GCM was enabled).
BUG tasks — direct push to develop — Implementing a BUG from Task Center, chat (build_feature / dispatch_background_task), or the Implement button now runs on develop and pushes to develop after tests — no feature branch, Merge button, or Offer to merge on the Agents tab.
BUG reports — same number as Task Center — New BUG items store a canonical path like docs/bugs/BUG-042-short-title.md where 042 matches Task Center #42. Planning chat and create_task_center_item tell the agent to use that path and heading — not a separate repo-wide BUG counter.
New project — repository initialization — Greenfield projects with a customer now initialize the Azure DevOps repo using platform or customer credentials even before a clone URL exists. If initialization fails, the project is still created and you land on the project with Initialize repository / Retry initialization on Overview and Edit instead of staying on the create form with no next step.
Chat — mobile readability — On phones, agent replies use the full screen width so lists and long answers are easier to read; your own messages stay slightly inset so the conversation stays clear.
Task agent activity on task detail — Under Implementation & review, see a Delegate workflow strip (where you are in Open in chat → Implement → Merge), an Agent activity timeline (runs and merge events with links to the Agents tab), and plain-language next step hints.
Merge recovery on the task — When merge to develop fails, the task shows a short explanation and Retry merge (architects/admins) without opening the Agents tab first.
Implement guardrails — Implement stays disabled when an agent run is already active or completed for this task; use Amend or Merge instead (details on the activity panel).
Unified project chat for task elaboration — Task detail no longer shows an embedded chat column. Use Open in chat to land in project chat focused on that task (your current chat topic is archived first when needed).
Boot Camp daily summary — Dashboard shows a Boot Camp daily summary card with overdue, stale, and next tasks. Optional daily email and browser push; toggle under Profile → Notification preferences and Push notifications.
Task reminders — Overdue and stale assigned tasks can trigger email, bell, and push nudges (once per day per item unless snoozed). Snooze from the dashboard digest card or ask in project chat.
New topic — open tasks — After New topic, tap a task button in chat to focus elaboration on it (no internal ids shown). Same flow from Open in chat on task detail.
MCP — stdio default everywhere — Settings → Boot Camp MCP, User Guide → Developers, and repo Sync now use the stdio proxy (@strikeforcealpha/bootcamp-mcp) as the committed mcp.json shape. Project id stays in .cursor/bootcamp.json only. Legacy HTTP path OAuth is documented as optional.
MCP — developer guide for local stdio proxy — User Guide → Developers documents @strikeforcealpha/bootcamp-mcp (stdio setup, tool list). Full reference: Docs → Guides → Boot Camp MCP — local stdio proxy.
MCP — @strikeforcealpha/bootcamp-mcp on npm — The local stdio proxy is published on the public npm registry (npx -y @strikeforcealpha/bootcamp-mcp). Copy the stdio snippet from Settings → Boot Camp MCP.
MCP — local stdio proxy (@strikeforcealpha/bootcamp-mcp) — Recommended setup for Cursor, VS Code, and Claude Code: OAuth runs in a local npx process; hosted tools (sync_repo, etc.) forward to the portal; local tools help clone repos and write IDE config. See Settings → Boot Camp MCP for stdio snippets.
Settings — MCP OAuth only — Static Bearer tokens (mcp_*, mcpu_*) and Generate token are gone. Settings → Boot Camp MCP shows OAuth-only mcp.json snippets for Cursor, VS Code, and Claude Code. Use Connect in your IDE after copying the path-scoped URL.
responses.md) on the project repo.Tasks — mobile board — On phones, the Board tab shows your tasks in a scrollable list grouped by status (same tasks as the desktop column board).
Tasks — detail and chat layout — On desktop, task detail and elaboration chat sit side by side again; drag the vertical gutter between them to change how much space each pane gets. In task chat, drag the grip above the message box to resize the composer.
Tasks — assignee filter — In the project Task center, open search/filter and pick any project member as assignee (not only yourself or unassigned).
Chat — saving your updates — Starting a New topic or Create task is more reliable when landing doc changes onto the project: the server refreshes git credentials and reconciles the integration branch before push, with automatic help on common shared-doc conflicts.
Bug fixes — faster turnaround — Bug tasks dispatched from Task Center can land on the integration branch right after automated tests pass, without waiting for a separate merge review step.
Login — workspace signup paused — Create a workspace is temporarily unavailable while the sales funnel is finished. Use Request access instead.
Login — Request access — Opens a short sales chat that asks about your goals and challenges; your answers are emailed to the Strike Force Alpha team so we can follow up personally.
Chat — Save docs — General planning chat has a Save docs button that lands your documentation onto develop without starting a new topic or creating a review task. The conversation stays open.
Chat — Update task — When chat is linked to a Task Center item, Create task becomes Update task: it lands doc changes onto develop, then adds a comment and assigns the task. Use Implement on the task page when you are ready for code.
Chat — documents panel — The duplicate Documentation in this conversation strip above the message list is gone; use the Documents in this chat panel on the right instead. That panel lists docs/ files only (not source code). Drag the resize handle between chat and the panel to give yourself more room.
Chat — saving your doc updates to the project — When you start a New topic, Create task, or reopen an archived conversation, the portal saves your pending chat edits to the project first and waits for that step to finish. You see Saving your updates to the project… while it runs; if something blocks the save, you get a plain-language message (no git jargon) and can fix the issue or try again instead of losing work silently.
Chat — Create task — The modal action is Create task (not “Send for review”). Your doc changes are saved to the project before the review task is created, so the task starts from what you actually wrote in chat.
Chat — one workspace per person — Project chat, task elaboration, and restored archives for the same person share one doc-editing workspace on the server, so you do not get conflicting half-saved copies across those surfaces.
Chat — when save fails — If the project cannot accept your updates (for example a merge conflict on shared docs), your team’s architect gets a Task Center item and notification so someone can help; you stay in chat with a clear error until it is resolved.
Onboarding assistant — The bottom-right help chat on home, product, and guide now loads a Boot and early Analyse playbook together with the portal guide on your first message, so answers can follow the same stages as the Getting started wizard, Docs, and project Chat.
Account — self-serve onboarding quality — The trial path from /signup through your first project and a completed Getting started flow is covered by the portal integration test suite alongside other release checks, which reduces the risk of regressions during sign-up.
Projects — Git migration (inbound / outbound) — Migrate repository opens with Inbound (mirror or single branch → migration branch) vs Outbound (probe → Continue to transfer from hosted repo → customer remote; full mirror uses force so an initial customer branch/README can be replaced). PATs stay server-side.
User Guide — stay in the app when signed in — /guide opens inside the normal dashboard shell (sidebar, top bar, avatar) when you are logged in; only anonymous readers see the slim marketing-style header.
Settings — MCP examples for all IDEs — Boot Camp MCP on Settings → AI now shows copy-ready examples for Cursor (.cursor/mcp.json), VS Code (.vscode/mcp.json with servers / type: http), and Claude Code (mcpServers in .claude/settings.json), matching what repo sync commits per portal projectId.
Developers — VS Code MCP OAuth client ID — The User Guide Developers tab now states explicitly: for VS Code manual OAuth / registration, use Client ID sfa-bootcamp-public with an empty client secret; sfa-bootcamp-client must not be typed in that form (it led to invalid_client on the authorize URL). The tab also documents where VS Code stores mcp.json (e.g. %APPDATA%\Code\User\mcp.json on Windows) versus Cursor’s .cursor/mcp.json.
Projects — overview — The project Overview tab no longer repeats the Chat, Tasks, Docs, Agents, and DevOps shortcuts as a second row of cards; use the tabs at the top of the project for those sections. Boot discovery and setup cards stay on Overview when they apply.
Projects — clone URL / default branch — After Getting started provisions a new Azure Repos repo, init-project sets the repository default branch to develop. A plain git clone <url> then checks out develop, consistent with Boot Camp’s integration branch. Older repos keep whatever default branch they already had until you change it in Azure DevOps.
Tasks — Boot discovery copy — Getting started now creates the Complete Boot stage discovery task (stage, not phase) with a clearer description of Boot discovery deliverables and the Boot → Analyse gate.
Settings — reliability — /settings is covered by session middleware, font preferences are validated so corrupt values cannot break the page, and after re-login you return to the page you opened (not always the dashboard).
Chat — task elaboration opening context — The first message in Elaboration chats for a task shows only the task title and description. Document linking and screenshots are handled by the assistant using the same tools as before (no tool names shown to readers).
Projects — Edit → Implementation merge — Choose platform PR flow (default), portal merge only, or portal merge + optional develop→main review PR per project so agent merges match whether you rely on Azure DevOps PRs or portal-owned merges. Bitbucket-hosted git follows the same Create/edit project and credential flows documented under Projects and User Guide → Developers.
Chat — PDF diagrams and scans — Uploaded PDFs still send extracted text first. Pages with embedded images get selective PNG derivatives for the vision model; scan-only PDFs (no extractable text) automatically rasterize the first pages up to a safety cap. Operators can tune caps via optional env vars in ENV_SETUP.md. To cite an uploaded file from product documentation or bugs paths in the repo, link assets/portal-uploads/… in repo-relative Markdown; reuse uploads via Chat / Tasks pickers instead of duplicating files.
Projects — migration wizard on create — On Create project, after you select a customer, you can check Open migration wizard after create to mirror a legacy repository into the new Azure DevOps repo once it exists (in addition to the existing flow when you already enter a source repository URL). Start mirror stays disabled until the project has a destination git URL; complete Getting started or DevOps setup first if needed.
Projects — token widget full report link — View full report on the project Token Usage widget opens Cost tracking (/costs) with the current project pre-selected in the filter (no broken /projects/…/costs path).
Rules — Company tab for tenant architects — Company rules lists projects by organization, edits .cursor/rules/project/ per clone, and adds Push Boot Camp template (after sync-rules) scoped to the selected project’s company — same push API as Push Rules, with per-project access checks for non–platform-admin users. GET/POST/PATCH/DELETE /api/projects/…/rules/project now authorize like project edit (ADMIN always; ARCHITECT with tenant/project visibility).
Navigation — Customers hub is platform ADMIN only — The sidebar Customers entry and + New Customer appear only for ADMIN. Architects, developers, and business owners open tenant setup from Settings → Profile → Organization, which links to their workspace record (/customers/…). POST /api/customers (create tenant) is ADMIN-only; architects still GET their scoped customer list for project flows. /customers/new redirects non-admin users to Dashboard. BUSINESS_OWNER gains Settings in the sidebar and mobile nav.
Account — User Settings in tabs — /settings uses Profile, Display, and AI. Profile includes Organization (tenant workspace links), notifications, and billing where applicable; platform admins keep Customers in the sidebar for CRM. ?tab=profile|appearance|ai deep-links tabs; ?billing=upgraded stays on Profile.
Docs — stage vs phase — Public User Guide and in-app help prefer lifecycle stage (Boot → Maintain) when talking about the project; phase is reserved for internal spec/ADR slices inside engineering documents. Landing, demo, tutorial, and help copy updated for consistency.
Projects — lifecycle stage — The Projects grid and each project header show the current methodology stage (Boot → Analyse → Develop → Launch → Maintain). Edit Project (admins and architects) includes a Lifecycle section to change the stage; platform admins may use Override Boot → Analyse gate when required Boot Discovery fields are incomplete. New non-platform projects start in Boot; demo/tutorial projects stay in Develop.
Tenancy — architect accounts — Users with the Architect role now only see customers and projects they belong to (same company/workspace), including the Create project customer list, dashboard, cost tracking, tasks, activities, rules project picker, and MCP single-project fallback. Platform-wide visibility remains for Admin only. If your team previously relied on Architect for cross-customer support, assign Admin for those accounts.
Account — self-serve signup — New tenants created via /signup get a Business owner as the first user (subscription/account admin). They can complete Getting started, manage billing and BYOK for their customer, and run init-project when they are project admin on the first project the wizard creates.
Projects — Agents — Completed executor runs may show Anthropic session (UUID) when Claude Code JSONL on the worker contains session_id / sessionId, so you can match rows in Anthropic Usage & Cost to a specific agent run.
Cost Tracking — Anthropic invoice reconciliation (admins) — On Cost Tracking, platform admins can sync a persisted Anthropic cost_report snapshot (org Usage & Cost API), refresh the comparison against portal cost_tracking estimates, and see variance in USD and percent. An optional Anthropic workspace id narrows vendor totals per tenant. Daily vendor buckets allow up to 31 days; longer dashboard ranges still show summary charts for the full period, while reconciliation uses the clamped window (called out in the UI). Advanced users can still fetch live raw JSON without the database.
Projects — token cost counter widget — The project dashboard now displays a Token Cost Counter widget showing AI token usage and estimated spend across Portal chat, Agent runs, and BYOK (customer-provided API keys). Toggle between 7-day, 30-day (default), and 90-day periods to track consumption trends. Admins and architects can drill down to a detailed cost report.
Marketing — home navigation — The public home header uses a single Product & pricing link to /product (no separate Pricing item) and adds Documentation → /guide. The /product header and the public shell (/ read-only routes such as /guide) use the same Product & pricing + Documentation pattern for parity.
Integrations — onboarding agent export — Operators can set ONBOARDING_GUIDE_AGENT_SECRET and call GET /api/guide/for-agents with Authorization: Bearer to fetch ONBOARDING_AGENT.md (same file as in the repo) — full context on /getting-started, Admins-tab gating, and Git host steps without relying on a logged-in browser.
Portal — onboarding assistant widget — When ANTHROPIC_ONBOARDING_AGENT_ID and ANTHROPIC_ONBOARDING_ENVIRONMENT_ID are set (with ANTHROPIC_API_KEY), a bottom-right “getting started” chat bubble appears on home, /product, and /guide; the Ask Boot Camp presales bubble is bottom-left there. Uses @anthropic-ai/sdk with client.beta.sessions (upgrade to 0.95+ if you see session create errors). Assistant replies render as Markdown (lists, links, emphasis) in the bubble. The first session turn injects ONBOARDING_AGENT.md from disk (same bytes as GET /api/guide/for-agents for external automation; no portal self-HTTP). Set ONBOARDING_GUIDE_AGENT_SECRET so off-portal callers can use GET /api/guide/for-agents — see ONBOARDING_AGENT.md.
User Guide — Getting started wizard — The Users tab documents the /getting-started four-step flow and a short GitHub / Bitbucket checklist (HTTPS URL, PAT or app password, Test connection). Dashboard help links to the anchor #getting-started-onboarding.
User Guide — public /guide — The User Guide is available without signing in at /guide (minimal header with Product & pricing, Documentation, and Sign in / Dashboard). Same tabs and content as before; anonymous visitors see a short Public guide notice and sign-in links for onboarding and admin quick steps — useful for external documentation agents and prospects.
Marketing — one demo block, one pricing page — Home and /product share the same See Boot Camp in action section (video embed when NEXT_PUBLIC_GTM_DEMO_VIDEO_URL is set, otherwise a Video placeholder plus Launch interactive demo). Subscription tiers (trial / seats / tokens) live only under /product#pricing; the home page Engagement models block links there. Public assistance is a floating chat bubble on / and /product only (fixed built-in widget id; no env, no operator “create widget” flow).
Billing — trial ending soon — During the last four days of a 14-day trial, a notification appears at the top of the dashboard (all roles notice it; Business owners, architects, and admins get Starter / Team / Business checkout buttons). Settings → Billing & usage shows the same upgrade actions and a confirmation when you return from Stripe (?billing=upgraded). POST /api/internal/cron/trial-data-retention (header x-cron-secret, same as other crons) schedules 30-day retention after trial lapse or subscription cancel, then purges due tenants.
Getting started — embedded onboarding wizard — After /signup, /getting-started is now a four-step flow on one page: create your first project (type and optional Git host URL), connect a PAT when you use Azure DevOps / GitHub / Bitbucket (with Test connection for GitHub and Bitbucket), initialize the workspace (runs init-project and shows live status when an execution server is connected), then capture company values for Boot discovery and open a starter Task Center item. Progress still persists on the customer record.
Account — self-service /signup and getting started — New tenants can pick Starter / Team / Business or a 14-day trial, accept terms, and complete Stripe Checkout (or sign in immediately after trial). Use /getting-started for a short four-step wizard with progress saved on the customer record. Settings → Billing & usage shows plan limits and opens the Stripe Customer Portal when a billing profile exists. Operators can hit /admin/billing for a read-only overview.
Marketing — landing and /product — Home and Product copy now cite 500+ methodology rules in the headline stats and refreshed greenfield, migration, architecture, and delivery archetypes so first-time readers see breadth before they sign up.
Chat — streamed replies stay single-copy — Tab switches, viewport resizes, and route revisits no longer stack duplicate streaming paragraphs in the transcript — streamed deltas and hydrated history cannot double-apply anymore. Full write-up — BUG — duplicate streaming text on remount.
Chat — lighter “generating” feedback — The extra Assistant is generating a reply banner above the message list is gone; status stays beside the composer you already watched.
Chat — clearer document tray — The tray now signals documents cited by bare filename or link separately from documents the agent opened with read tooling so you see “mentioned” versus “actually read.” Markdown previews follow documentation cross-links without dead relative URLs, and citations in prose stay linked into the tray.
Projects — Boot discovery intake (/projects/…/boot-discovery) — Complete the Boot wizard (company values, goals, metrics, and notes) directly in the portal; answers persist via the lifecycle APIs used by gated stage moves and planning-chat context injection.
Projects — GitHub repositories — Create/edit project exposes GitHub alongside Azure DevOps and Bitbucket: supply HTTPS repo URL plus the customer PAT, run the credential Verify handshake, then onboard with product code cloning into src/ while Boot Camp scaffolding remains at repo root once devops onboarding runs.
Operations — tenant-scoped Claude usage isolation (non-BYOK customers) — The portal can optionally provision isolated vendor workspaces, store organisation-held API keys with the same encryption posture as BYOK, and tighten dispatch checks so malformed SFA-managed keys never silently downgrade to pooled platform keys — improving per-customer cost reconciliation. Operators configure provisioning per ENV_SETUP; end-user tooling on the Customer record expands in subsequent phases documented there.
Customers — Azure DevOps Re-provision / Repair runs Anthropic workspace ensure — After successful ADO and demo-repo alignment, the repair flow now invokes the same idempotent Anthropic workspace provisioning used elsewhere for admins: repeat clicks succeed when a workspace is already linked, BYOK tenants are skipped, missing portal administrator API setup skips cleanly without undoing DevOps repair, and the success banner summarizes the Anthropic outcome.
Chat — Documents you discuss now appear in a side panel on desktop — Open any project chat on a desktop screen (≥ 1024 px wide) and the right-hand pane lists every document the conversation has touched: files the agent reads or edits, documents returned by a search_docs query, and any internal doc link or path the agent renders in its reply. Click a row to preview the document inline, side-by-side with the conversation, so you can keep the chat and the doc visible together. The split is a draggable gutter — your preferred width is remembered per browser.
Chat — Mobile keeps the existing layout, with a "Docs in chat" chip in the composer — Below the desktop breakpoint the chat is single-column as before. A new Docs in chat chip in the composer action bar shows how many documents the conversation references and opens the same list as a sheet when you need it.
Chat — Pin a doc to keep it in sync with agent edits (desktop ≥ 1024 px) — Hover any row in the Documents in this chat tray (or open the document in preview first) and use the Pin icon. The pinned doc gets a violet Pinned: <path> header with an Unpin action, and it now refreshes itself whenever the chat agent successfully edits or writes that file — usually within a second. A subtle Updated just now indicator fades in on each refresh so you can see when the pane caught up.
Chat — Doc deep-links open pinned, not just preview — When you click Chat about this on a document (or share a chat link with ?context=doc:<path>), the right pane now opens that doc in pinned mode automatically, so any edits the agent makes during the conversation flow into the pane in real time.
Chat — Pin and Unpin are available from two places — On a tray row (icon-only, hover-revealed) and in the preview-mode header (both icon + tooltip). Unpin always returns to the regular preview of the same doc — the tray entry is preserved.
Admin — Customers BYOK — The Customers grid shows BYOK / No BYOK beside provisioning status. Agent dispatch no longer falls back to the platform Anthropic key when BYOK is enabled but the stored key cannot be decrypted (align portal and execution server BYOK_ENCRYPTION_KEY). Affected customer contacts get email when outbound mail is configured.
Admin — Pre-Sales navigation — Pre-Sales is listed in the sidebar and mobile admin menu so you can open the widget manager in one click.
Customers — record page stability — Customer detail requires current database migrations (plan, billing, and BYOK fields). After upgrading the portal, apply pending migrations before opening Customers so the page does not error.
Task Center — share a task link — On any task detail page, use Copy link to share this task (link icon beside the branch/chat shortcuts). Your clipboard gets the full portal URL (/tasks/…), including from=project-… so the recipient lands on the same task with the correct back to project tasks breadcrumb context.
Marketing — /product and pre-sales widget — The public Product page (/product) summarises commercial plans (Trial through Business), an optional demo-video area, and clear routes to the interactive demo and sign-in. The home landing page links to Product, and the top Pricing link opens the Product page pricing section (/product#pricing). After you create a Pre-Sales widget under Admin → Pre-Sales, the home page can show the pre-sales chat bubble once your hosting is wired for it. Operators: see ENV_SETUP for deployment and environment wiring.
Customers — GitHub & BYOK — Admins can store GitHub personal access tokens alongside Bitbucket (project creation and credential test flows). Bring-your-own-key (Anthropic) can be enabled on the customer record: validate the key, store it encrypted, and use it for planning chat and agent runs when your platform team has turned on BYOK consistently in the portal and the execution server (see ENV_SETUP). The portal and executor must use compatible encryption settings so agent tasks can apply customer-held keys.
.cursor/mcp.json now standardises on a single path-scoped OAuth URL (…/api/mcp/{projectId}), with no X-Bootcamp-Project-Id header in git-managed templates. Repo sync, Rules compliance, node bootcamp-scripts/sync-rules.mjs, Settings → Boot Camp MCP, and the User Guide Developers tab all match ADR-068 and the public Boot Camp MCP OAuth wiring documented in-app. The global MCP endpoint plus header remains a runtime escape hatch only.TASK_AMENDED_RELAUNCHED event (branch name and amendment document paths) so the team can see who restarted work on the existing implementation branch.sfa-bootcamp-public, no client secret, and the hosted callback https://vscode.dev/redirect. The developer guide and Settings MCP card now show the VS Code servers config shape and manual registration steps.Not yet full product UX in the portal:
Redis-backed persistent chat sessions
Executor token tracking
<< Back to documentation home
Credentials are stored encrypted on the server and are not shown again after you save. For MCP and local IDE setup, open the Developers tab in this guide; rule layout for contributors is under Rules for developers (same Users tab).
"What Boot Camp stage should this project be in?"
"Generate a feature spec for the notification system"
The assistant reads your attachments so it can summarize, compare, or answer questions about them. Supported types and how they are processed:
.doc, .docx) are not accepted; save or export as PDF first..xlsx and .csv are supported (sheet and cell text is extracted for the AI)..ts, .md) as plain text.If an upload is rejected (for example a Word document), the portal shows a short message explaining what to use instead. Partial uploads still work: valid files are sent; failed ones stay in your attachment list so you can remove or replace them.
Backlog
Roadmap proposals: high-level features and bugs. Use 'Elaborate in chat' to scope items; once scoped and accepted, add them to the roadmap (docs/ROADMAP.md).
Documentation
Browse project docs from the repo (specs, ADRs, mockups) in a tree view. Rendered in the portal so you don't need to open the repository.
developdocs/contributions/.Features: Discuss in chat on a topic branch; have the assistant create or update the feature spec on that branch, then promote and merge via a FEATURE or BUG task in review.
Bugs: Same pattern: reproduce and scope in chat on the branch, merge when reviewed, then reflect delivery in docs/ROADMAP.md.
Summary
BACKLOG; create a FEATURE or BUG task to capture a new idea.chat/* branch; assistant writes specs on that branch.docs/ROADMAP.md after stakeholder acceptance.Full details: project documentation includes a Tips for business owners & analysis page (linked from the Docs browser and from the ? help on Chat and Docs).
Run AI agentsAdmin
Launch agents to implement features, review code, run tests, or generate docs.
Each user has a role that determines what they can see and do in the portal. Your current role is shown in the top bar.
Full access — create projects, manage users, run agents, view costs, configure settings
Project management, agent runs, cost tracking, rules viewing. Cannot manage users or system settings.
View assigned projects, use chat, view docs. Cannot run agents or view costs.
View assigned projects, use chat. Read-only access to project information.
Projects
Create and manage software projects. Each project has its own chat, docs, and agent configuration.
AI Chat
Conversational AI assistant that knows the Boot Camp methodology. Ask about architecture, best practices, or let it create feature specs and tasks.
Task Center
Capture feature requests and bugs as tasks (status: Backlog). Use chat to elaborate, then dispatch for implementation via AI agents.
Documentation
Browse project documentation directly from the portal. Docs are fetched from the project repository and rendered in a tree view.
AI AgentsAdmin / Architect
Launch coding agents that run on execution servers. Agents can implement tasks, review code, run test suites, and generate documentation.
SkillsAdmin / Architect
Configure which capabilities are available to the AI agent for each project. Skills include code analysis, implementation, documentation, testing, and DevOps automation.
PersonaAdmin / Architect
Customize the AI agent's communication style, language preference, and focus areas. Persona settings apply to both chat responses and agent task output.
Cost TrackingAdmin / Architect
Monitor AI token usage and estimated costs across all projects. See which projects consume the most resources and track spending against your budget.
Every page has a help button (the ? icon) in the top area. Click it for context-specific guidance, tips, and links to related features. You can also ask the AI chat assistant any question about the platform.
Rules marked portal-only in their source file apply to in-portal planning chat only; they are omitted from the generated IDE bundle so your laptop Cursor is not supposed to enforce the strictest portal-only chat workflow. If behaviour still differs between teammates, compare whether each person opened the same repo root and pulled the same .cursor/rules commit.
Optional: Agent Skills for this repo live under .claude/skills/ (for example project develop / MCP usage). Enable or attach them in Cursor per your org policy. General rule layout is also summarised under User Guide → Users → Rules for developers.
Then configure the Boot Camp MCP server below so Cursor can call portal tools (repo sync, tasks, docs) with your account.
@strikeforcealpha/bootcamp-mcpRecommended for Cursor, VS Code, Claude Code, and Visual Studio. A local npx process handles OAuth; repo sync, tasks, and docs tools run on the Boot Camp platform (same permissions as the Boot Camp web app).
--portal only — project id lives in .cursor/bootcamp.json)..cursor/mcp.json; VS Code: user or workspace mcp.json with type: stdio).Do not put the project id in mcp.json. Use committed .cursor/bootcamp.json or repo-root bootcamp.json (repo sync writes these). Open the repo root as your workspace.
Local: bootcamp_get_setup_plan, bootcamp_ensure_local_clone, bootcamp_write_ide_config, bootcamp_doctor.
Platform: file read/write, git sync, Task Center, feature specs, ADRs, background agent runs, and more — on the Boot Camp platform for your role.
Full reference (tool list, CLI, troubleshooting): bootcamp.strikeforcealpha.io → your project Docs → Guides → Boot Camp MCP — local stdio proxy, or the npm package @strikeforcealpha/bootcamp-mcp.
Copy the stdio snippet from Settings → Boot Camp MCP into .cursor/mcp.json (or your user-level MCP config). On first tool use the local proxy opens a browser for OAuth — no Cursor Connect button required.
mcp.json — it lives in .cursor/bootcamp.json (repo sync writes this).@strikeforcealpha/bootcamp-mcp via npx.--project YOUR_ID once in user MCP config, or use bootcamp_ensure_local_clone — see Local stdio proxy.After repo sync or sync-rules.mjs, committed repos include stdio MCP config. Open the repo root as your workspace and reload MCP.
.cursor/mcp.jsonReplace YOUR_PORTAL_HOST with your Boot Camp portal origin (no trailing slash). Project id comes from .cursor/bootcamp.json.
{
"mcpServers": {
"sfa-boot-camp-alt": {
"command": "npx",
"args": [
"-y",
"@strikeforcealpha/bootcamp-mcp",
"--portal",
"https://YOUR_PORTAL_HOST"
]
}
}
}VS Code — stdio in workspace or user mcp.json
{
"servers": {
"sfa-boot-camp-alt": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@strikeforcealpha/bootcamp-mcp",
"--portal",
"https://YOUR_PORTAL_HOST"
]
}
}
}Repo sync and rules push rewrite legacy HTTP MCP configs to this stdio shape on all Boot Camp projects.
VS 2026 (and VS 2022 17.14+) can attach MCP to GitHub Copilot agent mode. Use the same stdio npx @strikeforcealpha/bootcamp-mcp args as VS Code (type: stdio in .mcp.json).
{
"servers": {
"sfa-boot-camp-alt": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@strikeforcealpha/bootcamp-mcp",
"--portal",
"https://YOUR_PORTAL_HOST"
]
}
}
}Use MCP servers (Visual Studio). Then Copilot Chat → Agent, enable Boot Camp tools, approve tool runs.
projectId or no access.