# Quasar product guide

Revision 2 — Quasar product guide, published 2026-10-23. https://guide.quasar.nuzzodevstudio.com/

## What Quasar is and who it is for

> Quasar is project-management software built so AI coding agents and people run the same project through the same rules. It covers issues, sprints, planning, documents, client quotes and documentation releases, and offers a REST API and an MCP server beside the web app. This chapter covers: - what problem Quasar solves; - who it fits: software teams and studios that work with coding agents, and organizations that deliver documentation and quotes to clients; - who it does not fit yet; - the principles behind it: agents as first-class users, every change recorded with who made it, safe retries, and strict tenant isolation. Read it first to decide whether the rest of the guide is relevant.

This guide describes Quasar **2026.10.15**. Where a statement depends on the version, it says so.

### In short

Quasar is a project-management tool for teams that build software **with AI coding agents**. An agent and a person work the same project: they read the same issues, follow the same workflow and are held to the same rules.

- **People** use the web app.
- **Agents** use the REST API and an MCP server (the Model Context Protocol, which coding agents speak natively).

Both reach the same services underneath. An agent cannot do anything a person could not, and the reverse is also true.

Beyond tracking work, Quasar carries the work to the client:
- documents reviewed and accepted on a revision;
- documentation published as frozen releases in PDF, Word, HTML and Markdown;
- priced quotes built from the issues' estimates;
- versions followed through the git repository.

### The problem it solves

Most project tools were designed for people clicking through screens. An agent can be connected to them, but the tool was not built for the agent:
- writes are not safe to retry, so a repeated call duplicates work;
- errors do not say which rule was broken;
- nothing distinguishes what an agent did from what a person did;
- the agent's working rules live in a prompt nobody maintains.

Quasar starts from the opposite end. A coding agent should read and update the project state as naturally as it reads and writes code. Every person and every agent that touches a project should also be able to see:
- what was decided;
- what the plan was;
- what was delivered.

### Who it is for

- **Software teams and studios that work with coding agents.** You plan in Quasar, your agents pick up issues, record their plan, move the work through the workflow, and log the time they spent. A person stays in charge: work sessions an agent opens become work logs only when a person confirms them, and the agent contract reserves the acceptance of documents to a person's word.
- **Teams that deliver to clients.** Quasar produces client-ready material from the same data:
  - quotes priced from estimates;
  - a client-facing summary per issue;
  - documentation released as frozen, accepted revisions.
- **Organizations that need isolation and an audit trail.** Every organization (a *tenant*) is isolated by the database itself. Administrative actions, sign-ins and changes to work are logged.
- **Teams that want to self-host.** The same product runs as a hosted service or on your own infrastructure.

### Who it is not for (yet)

- **Teams that need a mobile app.** The interface is designed for desktop screens.
- **Teams that need the interface in a language other than English, today.** The application is in English; Italian and French are next on the roadmap. Documents can be written in any language, and content templates exist in English and Italian.
- **Teams looking for a general-purpose wiki or chat.** Quasar's documents are structured, reviewed project documentation, not a free-form knowledge base.

The chapter *What Quasar does not do* lists the limits in detail.

### The principles behind it

- **Agents are first-class.** Every capability is designed for the API and MCP as much as for the screen. Agent tools are workflow-oriented: one call does what a person would do in one step, and every refusal explains the rule that refused it.
- **Everything is recorded, and by whom.** Each change is attributed to the person whose key or session made it, and Quasar marks when an agent acted on that person's behalf. Event logs keep the history of issues, documents and sprints.
- **Retries are safe.** Every write accepts an idempotency key, so a repeated call replays instead of duplicating. Every entity carries a version, so two concurrent edits conflict instead of one silently winning.
- **Nothing is hidden.** An action that cannot run is shown disabled, with the reason. A figure Quasar could not compute says so instead of showing zero.
- **Isolation is enforced by the database.** Tenant separation relies on PostgreSQL row-level security, not on a filter someone might forget.
- **Built with itself.** Quasar is planned, built and documented in Quasar, by AI agents working under the workflow it offers, with an architect who supervises and accepts. See *Crucial points and objections*.

### Where to go next

- *Capabilities by area* — everything Quasar does, one area at a time.
- *Working with AI agents* — how agents connect and what they can do.
- *Deployment, tenancy and security* — hosting options and how data is protected.
- *What Quasar does not do* — the limits, stated plainly.

## Capabilities by area

> Everything Quasar 2026.10.15 does, area by area: - issues and configurable workflows; - epics and nested projects; - sprints, boards and metrics; - schedule and Gantt; - work logs, time and money; - client quotes; - documents with review and acceptance, releases and exports; - the asset library and artifacts; - search; - git and version tracking; - deadlines, project inbox and notifications; - users, roles and permissions; - public guides; - data export and retention. Read the section for the area the question is about; each lists concrete, user-visible capabilities.

What Quasar **2026.10.15** does, area by area. Everything listed here is available both in the web app and to agents through the API and MCP, unless a section says otherwise.

### Issues and workflow

- **Issue types.** Epic, Story, Task, Bug and Sub-task. An issue's type and project never change after creation.
- **Keys and references.** Every issue has a readable key per project, such as `ABC-00042`. Anywhere an issue is referenced, its key, its id or its in-app link all work.
- **Statuses.** Backlog, To do, In progress, Testing, In review, Done and Reopened. Each organization can rename them to its own words.
- **Configurable workflow.** Which status may follow which, and on what condition, is a workflow drawn in a graphical editor. It is set for the whole organization and can be refined per division, team or project. Available conditions include:
  - required sections filled in;
  - no open blockers;
  - a role or the assignee;
  - a current, verified plan;
  - a Definition of Done satisfied;
  - time logged;
  - the code having reached a given branch or version line.

  A refused move says which condition failed and why.
- **Closing work.** Every Done carries a resolution: Fixed, Won't fix, Duplicate, Cannot reproduce or Incomplete. Work closed as not delivered can go to Done from any status.
- **Sizing and dates.** Severity, story points, time estimates, planned start and due dates.
- **What an issue produces.** Delivery, investigation, technical or management work. Velocity counts delivery, and the rest is reported beside it.
- **Typed sections.** Sections such as pre-analysis, decisions, verification and resolution, configurable per project.
  - A pre-analysis can list the files it examined with their checksums.
  - It goes *stale* when those files change, so a plan made on old code is visible as such.
- **Definition of Done.** Checklists defined at organization, division, team or project level, copied onto each issue.
- **Relations.** Relates to, caused by, duplicates and blocks.
- **Discussion and files.**
  - Comments on the description or on a single section.
  - Attachments, downloadable once the antivirus allows.
- **For the client.** A client-facing summary per issue, kept apart from the internal text.
- **History and trash.**
  - Every change is in the issue's history.
  - Deleted issues go to the project's trash and can be restored.
- **Ordering and views.** Manual ordering by drag and drop, a "My issues" view, and a home page that adapts to newcomers and to experienced users.

### Epics and projects

- An **epic** groups related issues. It has no sprint, points or severity of its own, and its progress is the progress of its children.
- **Projects nest.** A project can hold sub-projects, up to a depth the organization chooses. Totals over a project and its sub-projects add up the leaves, per currency, and say when they could not see everything.

### Sprints, board and metrics

- **Sprint lifecycle.** A sprint is Created, Active, then Closed or Cancelled, with one active sprint per project. Closing a sprint asks what happens to unfinished work. Each sprint has planned and actual dates and an overdue signal, and can be archived.
- **Target version.** A sprint can name the version its work goes into.
- **Board.** One column per status. Dragging a card moves the issue, and the workflow still applies.
- **Backlog versus unplanned.** The backlog is work not yet started; *unplanned* is work in no sprint. Quasar keeps the two apart.
- **Metrics, computed when you look.** Sprint report, burndown, velocity and cumulative flow.
- **Workload.** Each person's load against an even share of the sprint's capacity. An over-capacity signal warns and never blocks.

### Schedule and Gantt

- **One schedule.** The schedule is computed by Quasar itself, so every screen and every agent sees the same dates.
- **Working calendar and time zone.** Working hours, working days and holidays, inherited from the organization down to each project, and a time zone per scope.
- **Gantt chart.**
  - Rows by assignee, parent, sprint or status.
  - Move and resize bars with the mouse or the keyboard.
  - Critical path and slack shown.
  - An equivalent table for screen readers.
- **Proposals, never automatic.** Quasar can propose a sprint end date from the work in it.

### Work logs, time and money

- **Work logs.** Hours per issue, at the hourly rate in effect when the time was logged. A later rate change never rewrites history.
- **Corrections.** The author can correct a work log for 15 minutes. A project lead can correct any, and only a lead can change the rate.
- **Currencies.** One currency per project, with an organization default.
- **A first figure.** Where an issue has no work log yet, Quasar proposes one from the time the issue spent In progress. Nothing is recorded until someone confirms it.
- **Agent sessions.** The time an agent spends is measured by Quasar's clock and proposed as a work log, which a person confirms.

### Client quotes

- A **quote** is a priced offer generated from a sprint or a selection of issues, with line items, narrative sections and a total.
- **Lifecycle.** A quote is Draft, Sent, then Accepted or Rejected. Sending freezes it; to change a sent quote you clone it.
- **Templates and review.** Each organization configures templates and fixed blocks. A person reviews the quote before it is sent.
- **Export.** A self-contained HTML file.

### Documents

- **Typed documents.** Markdown documents of built-in types such as architecture decisions, design documents, runbooks, user manuals and API specifications. Each type comes with a template, and each organization and project chooses the types it uses.
- **Summary and language.**
  - Every document has a summary, so a reader or an agent can judge it without opening it.
  - Every document has a content language. Built-in templates exist in English and Italian.
- **Derived documents.** A translation or a client rendition declares its source document. Quasar then shows whether it is aligned with that source, stale or unverifiable.
- **Review and acceptance.** A document moves from Draft to In review to Accepted, and an acceptance can be revoked.
  - An acceptance binds to the exact revision of the text.
  - A later edit shows as *modified since acceptance*.
- **Export.** PDF, Word, HTML or Markdown. Each file states its organization, key, revision and acceptance.

### Documentation releases

- **A release is a frozen set of documentation.** It is a tree of chapters and sections, heading levels 1 to 6, published in numbered revisions.
- **Building a revision.**
  - You attach documents, which are copied in and split at their headings.
  - Quasar shows when a source document changed since.
  - You can update from the source with a side-by-side preview.
- **Publishing.**
  - A revision is accepted as a whole, then published.
  - Publishing cannot be undone; to change a published release you revise it into a new draft.
  - Everything that stops publication is listed at once.
- **Files.** Each published revision is rendered once to PDF, Word, HTML and Markdown and served from storage.

### Asset library and artifacts

- **Asset library.** Icons, screenshots and image collections, with one file per role, theme and language, and advice on what is missing. Images inserted in documents are pinned when a document or release is delivered.
- **Artifacts.** The packages, binaries, container images and archives each version delivers.
  - The checksum is verified on upload.
  - An artifact is immutable once uploaded.
  - Antivirus status is shown.
  - An artifact can be withdrawn with a reason.

### Search

- **One search box per project.** It covers documents, issue descriptions, issue sections and comments, with results grouped by kind.
- **Full-text.** Phrases, `or` and exclusion with `-`. Results respect what the reader may see.

### Git and versions

- **Repository observation.** A project can observe one repository on GitHub, GitLab or Bitbucket Cloud. Quasar shows:
  - where each issue's code is along the chain of branches, from the issue key in the commit subjects;
  - pipeline results;
  - the version file;
  - the changelog between release tags.
- **Read-only, always.** Quasar never writes to a repository. Its one write is the webhook subscription that tells it about new commits.
- **Version flow.** For teams that use version branches and release tags, Quasar proposes the git commands for each step and checks that each step happened. It never runs them.
- **Shared resources.** A project can declare shared resources, such as a test environment, that deploy scripts check before using.

### Deadlines, inbox and notifications

- **Deadlines.** Dated facts from outside that may break something, such as a certificate expiring or a provider changing a host.
  - Kept per organization or per project, and they can repeat.
  - Email reminders go out ahead of time, by default 30, 7 and 1 days before.
  - Each occurrence is marked handled, with a note.
- **Project inbox.** Notes for requests nobody has decided on yet. Each is later promoted to an issue, discarded or ticked done.
- **Live updates.** Open pages refresh when the data under them changes.
- **Email.** Used for deadline reminders and password resets.

### Users, roles and permissions

- **Organization roles.** Admin, Member and Viewer.
- **Project access.**
  - Project roles are Project manager, Member and Viewer.
  - Divisions and teams group people and projects, and can adjust access.
  - The project always has the final word.
- **Hidden versus refused.** Someone with no access to a project does not see it exists. Someone who can see it but lacks the right gets a clear refusal.
- **Managing people.** Invitations, deactivation, and service accounts for automations.
- **Sign-in and second factor.**
  - Sign-in with Quasar's own accounts or an OpenID Connect provider.
  - A second factor by authenticator app or security key, which an organization can require.
  - A fresh second factor is required for sensitive actions.
- **Audit log.** Administrative actions and sign-ins.

### Public guides

- **Public publications.** An organization can make one of its documentation releases readable by anyone, without an account:
  - as web pages;
  - through a read-only REST API with an OpenAPI description;
  - through an MCP server for AI agents.
- **Quasar's own guide.** Every installation serves Quasar's own product guide the same way. This guide is one.
- The chapter *Working with AI agents* explains how agents use them.

### Data export and retention

- **Personal data export.** Every user can export their own data as JSON.
- **Trash retention.** Deleted items are kept for a period the organization sets, then purged.
- **Erasing a user.** The user is anonymized in place, so the history stays consistent without naming them.

## What Quasar does not do

> The limits of Quasar 2026.10.15, stated plainly, so nobody discovers them after buying. Covered: - interface: English only, desktop only; - search: full-text within one project, no semantic or AI search; - git: Quasar never writes to repositories, never runs git commands and never guesses versions; - integrations: no outbound webhooks, no chat integrations, MCP authenticates with API keys only; - documents: no WYSIWYG editor, published releases are permanent, export format limits; - planning: no per-person capacity; - security: no SMS codes, antivirus off unless configured, no in-app restore of backups; - public guides: images not shown yet, no self-service custom domains. Read this before recommending Quasar for a specific need.

The limits of Quasar **2026.10.15**. Some are deliberate choices; others are gaps that may close in a later version, and each says which.

### Interface

- **English only, for now.** The application's own words are in English. The interface was designed to be translated, and languages are the next step on the roadmap, starting with Italian and French. Documents can already be written in any language, and built-in document templates exist in English and Italian. *A gap.*
- **Desktop only.** The interface is designed for screens 1,024 pixels wide and more. There is no mobile layout and no mobile app. *A gap.*
- **Accessibility.**
  - Quasar targets WCAG 2.2 level AA. Colour is never the only signal, contrast is checked in both themes, and the Gantt chart has an equivalent table.
  - It does not meet the *Reflow* criterion (1.4.10), because of the desktop-only layout.
  - It has not yet been tested by a screen-reader user.

### Search

- **Full-text, not semantic.** Search matches words as written, with phrases, `or` and exclusions. There is no fuzzy matching, no "did you mean", and no AI or vector search. *Deliberate:* where meaning matters, an agent reads summaries and picks what is relevant, which works across languages.
- **One project at a time.** Search covers the current project, not its sub-projects and not the whole organization. *A gap.*

### Git and code

- **Quasar never writes to a repository.** It observes branches, commits, tags and pipelines. It never creates a branch or a tag, merges, or commits. Its one write is the webhook that notifies it of new commits. *Deliberate.*
- **It never runs git commands for you.** In the version flow it proposes the exact commands and checks afterwards that they happened.
- **It never guesses.**
  - A version is never inferred from a branch name.
  - An issue is linked to a commit only when the commit's subject carries the issue key.
- **One repository per project.**

### Integrations

- **No outbound webhooks.** Quasar does not call other systems when something changes. Agents and scripts use the REST API or MCP instead. *A gap.*
- **No chat integrations** (Slack, Teams and the like). *A gap.*
- **MCP authenticates with API keys only.** Agents connect with a personal key or a service-account key; there is no browser sign-in flow for MCP clients. *Deliberate:* it was built and removed because no client used it.
- **Email is used sparingly.** Deadline reminders and password resets only; there are no notification digests by email.

### Documents and releases

- **Markdown, not WYSIWYG.** Documents are written as Markdown text and shown rendered; there is no visual editor.
- **Published releases are permanent.**
  - A published revision cannot be unpublished or edited; you revise it into a new draft.
  - Uploaded artifacts cannot be replaced, and a withdrawal cannot be undone.
- **Export limits.**
  - The PDF has no page numbers in its table of contents.
  - The PDF shows PNG and JPEG images, and Word also shows GIF.
  - Chinese, Japanese and Korean text does not print in the PDF.
  - The Markdown export carries no library images.
  - Quotes export as HTML.
- **No image generation.** The asset library does not render icon sizes from a vector master. You upload each file.

### Planning

- **No per-person capacity.** Sprint workload compares each person with an even share of the sprint's capacity. There is no individual availability or holiday calendar per person; holidays are per organization or project. *A gap.*
- **Proposals, never automatic changes.** Suggested sprint end dates and first work-log figures are proposals a person accepts.

### Security and operations

- **No SMS codes.** The second factor is an authenticator app or a security key. *Deliberate.*
- **API keys carry no second factor.** When an organization requires two-factor authentication, the keys of a member who has not enrolled stop working.
- **Antivirus is off unless configured.** Quasar supports ClamAV, and files above the scanner's limit are marked *not scanned*. A new installation has no scanner until one is configured.
- **Backups.** Taken and kept by the operator of the installation. There is no restore button in the application.

### Public guides

- **Images are not shown yet.** Public pages of a published release render text only; serving a release's images publicly is planned. Quasar's own product guide carries no images in this version.
- **No self-service custom domains.** The operator of an installation can map a host name to a guide, but an organization cannot attach its own domain by itself. *Deliberate:* certificates and domain verification are a product of their own.
- **One public release per publication.** An organization can publish several releases, each under its own address.

## Working with AI agents

> How AI coding agents work in Quasar 2026.10.15: - connecting an agent over MCP or the REST API with a personal or service-account key, including Claude Code and Codex setup; - what agents can do through about 120 workflow-oriented tools; - how Quasar keeps agents safe and accountable: same permissions as their person, read-only keys enforced by the database, safe retries, explanatory refusals, an "agent" mark on everything they do; - how a person stays in control: agents record their plan before coding, their time is measured but confirmed by a person, and the agent contract reserves acceptance of documents to a person's word; - the separate, unauthenticated MCP server of public guides, and how to connect this guide to Claude Code, Codex, VS Code, Cursor, Claude and ChatGPT (or read it with no setup from llms-full.txt). Read this to evaluate Quasar for agent-driven development, or to give your assistant this guide.

Quasar is designed for coding agents to work a project alongside people. This chapter describes version **2026.10.15**.

### Two ways in, one set of rules

- **MCP.** Coding agents such as Claude Code, Codex and opencode connect to Quasar's MCP server at `/api/mcp` (Streamable HTTP).
- **REST.** Scripts and integrations use the REST API under `/api/v1`.

Both call the same services as the web app. An agent's change goes through exactly the same checks as a person's: the workflow, the permissions and the validation.

### Connecting an agent

1. In **Profile → API keys**, create a key. It starts with `qsk_` and is shown once.
2. Give it to the agent as a bearer token: `Authorization: Bearer qsk_…`. Each client has its own configuration format. The in-app Help Center shows the exact lines for Claude Code, Codex, opencode and pi.
3. The agent now acts **as you**, with your permissions, no more.

**Key options:**
- **Expiry.** Keys expire after 90 days by default and can be revoked at any time; a revoked key stops working immediately.
- **Read-only keys.** A key can be created *read-only*. A read-only key is only offered the read tools, and the database itself refuses any write made with it.
- **Service accounts.** For CI and integrations, a service account holds its own keys and its own permissions. It can never be an organization administrator.

### What an agent can do

The MCP server offers about 120 tools. They are **workflow-oriented**: one call does what a person does in one step, rather than exposing raw tables. They cover:
- **Work:** issues and all their content (sections, comments, relations, checklists, attachments), projects, sprints and boards, work logs and the project inbox.
- **Documents:** documents and their review, documentation releases (composing, accepting, publishing), the asset library and artifacts.
- **Commercial:** client quotes.
- **Delivery:** versions, git status, pipeline results and changelogs, and deadlines.

**Built to be used by a model:**
- **Onboarding.** A new agent calls `get_started` first and receives the project's rules and the workflow it must follow.
- **Long-form help.** Each tool's detailed help is available on demand (`describe_tool`), so the tool list stays small.
- **Small models.** The tool surface can be narrowed for them.
- **Every refusal is actionable.** It names the argument or the rule that failed, lists the accepted values, and reports every problem at once.
- **Bounded reads.** Read tools never return unbounded payloads unasked: long texts are withheld until explicitly requested.

### Safe by construction

- **Retries never duplicate.**
  - Every write accepts an idempotency key, and a repeated create replays the first answer.
  - Every entity carries a version, and a write against an outdated version is refused rather than overwriting someone's change.
- **Same permissions as the person.** An agent cannot see a project its person cannot see. A project it has no access to does not appear to exist.
- **Everything is attributed.**
  - Each change is recorded under the person whose key made it.
  - Quasar separately notes that an agent produced it, and the web app shows an **Agent** badge.
  - Nobody has to declare this: it comes from the key.
- **Rate limits.** Each key has generous limits, so a runaway loop slows down instead of degrading the service.

### A person stays in control

Quasar's own workflow, which an organization can adopt and adapt, encodes how an agent should work:
- **Plan before coding.** Before an issue can move to *In progress*, the agent records a **pre-analysis**: the plan, and the files it examined with their checksums. If those files change before the work starts, the plan shows as stale.
- **Status tells the truth.** The issue moves to *In progress* before the first edit, so whoever supervises sees where the work is.
- **Time is measured, then confirmed.** The agent opens a **work session** at the start of each turn and closes it at the end. Quasar's own clock stamps both. A session becomes a work log only when a person confirms it.
- **Acceptance is a person's.** The agent contract tells an agent to accept a document or a release revision only on a person's explicit word. Every acceptance records whose key made it and whether an agent acted. To keep an agent from accepting at all, give it a key whose owner is not a project lead.
- **The code is followed, not trusted.** Quasar reads where each issue's code actually is in the repository, from the issue key in commit subjects, instead of taking the agent's word for it.

### The agent contract

The rules Quasar gives an agent are **versioned**. When something an agent may have written down becomes wrong, the version changes, and Quasar tells a connecting agent what changed since its version. A repository can keep a copy of the contract, which agents read at the start of every session.

### Public guides for any agent

Documentation an organization publishes, including this guide, can be read by agents **without any key**:
- **`{guide}/llms.txt`** lists every chapter with its summary.
- **`{guide}/llms-full.txt`** is the whole publication in one plain-text file.
- **`{guide}/api/v1`** is a read-only REST API, with an OpenAPI description at `{guide}/openapi.json` that can be imported as a ChatGPT Action.
- **`{guide}/mcp`** is a separate, read-only MCP server with the tools `index`, `read`, `search` and `fetch`. `search` and `fetch` follow the shape ChatGPT connectors and deep research expect.

The public MCP server shares nothing with the operational one: it has no access to any project, only to what was published. The intended use: read the chapter summaries, choose what is relevant, read those chapters whole, and cite their pages.

### Connecting this guide to your assistant

**Nothing to set up.** A chat assistant that can browse, such as ChatGPT or Claude, reads this guide from **`https://guide.quasar.nuzzodevstudio.com/llms-full.txt`** when you give it that address. Connecting the MCP server adds no content. It lets the assistant search and read chapter by chapter instead of loading everything at once.

The server's address is **`https://guide.quasar.nuzzodevstudio.com/mcp`**. It is a remote Streamable HTTP server that needs no sign-in. Each client below names it `quasar-guide`; any name works.

The steps were checked against each client's own documentation on **23 October 2026**. Menus and plan limits change, so if a step no longer matches, your client's documentation is the authority.

#### Claude Code

```
claude mcp add --transport http quasar-guide https://guide.quasar.nuzzodevstudio.com/mcp
```

Add `--scope user` to have it in every project. `claude mcp get quasar-guide` should then show **Connected**.

#### Codex CLI

```
codex mcp add quasar-guide --url https://guide.quasar.nuzzodevstudio.com/mcp
```

Or, in `~/.codex/config.toml`:

```toml
[mcp_servers.quasar-guide]
url = "https://guide.quasar.nuzzodevstudio.com/mcp"
```

#### VS Code

Run:

```
code --add-mcp '{"name":"quasar-guide","type":"http","url":"https://guide.quasar.nuzzodevstudio.com/mcp"}'
```

Or open this install link in a browser, and VS Code opens with the server filled in:

```
vscode:mcp/install?%7B%22name%22%3A%22quasar-guide%22%2C%22type%22%3A%22http%22%2C%22url%22%3A%22https%3A%2F%2Fguide.quasar.nuzzodevstudio.com%2Fmcp%22%7D
```

#### Cursor

Open this install link in a browser:

```
cursor://anysphere.cursor-deeplink/mcp/install?name=quasar-guide&config=eyJ1cmwiOiJodHRwczovL2d1aWRlLnF1YXNhci5udXp6b2RldnN0dWRpby5jb20vbWNwIn0=
```

Or add it to `~/.cursor/mcp.json`:

```json
{ "mcpServers": { "quasar-guide": { "url": "https://guide.quasar.nuzzodevstudio.com/mcp" } } }
```

#### Claude (claude.ai and Claude Desktop)

1. Open **Customize → Connectors**, choose **+ Add**, then **Add custom connector**.
2. Enter a name and the server address, and choose **No sign in** under authentication.
3. Turn the connector on in a conversation.

Every plan can add custom connectors; the Free plan allows one. On Team and Enterprise, an owner adds the connector first in **Organization settings → Connectors**, and members then connect it.

#### ChatGPT

In **Plugins**, choose **+**, then **Add custom MCP server**. Enter a name, a description and the server address, and choose **No authentication**.

Adding a custom MCP server depends on the plan and the workspace's permissions, and OpenAI changes it often. On Business, Enterprise and Edu, an administrator decides who can create one. Where your plan does not allow it, give ChatGPT the `llms-full.txt` address above instead: it reads the same content.

For deep research, the server's `search` and `fetch` tools answer in the shape ChatGPT expects, and every result carries the address of its page.

## Deployment, tenancy and security

> How Quasar 2026.10.15 is deployed and how it protects data: - hosted service or self-hosted, from one product; - single-tenant or multi-tenant, and what a tenant is; - what an installation needs: the app and its rendering worker, PostgreSQL, file storage, optional antivirus and mail; - tenant isolation enforced by PostgreSQL row-level security; - sign-in with Quasar's own accounts or an OpenID Connect provider; - two-factor authentication and step-up for sensitive actions; - API key controls and rate limits; - audit logs and event histories; - file handling, data export, retention and erasure; - how the software itself is tested. Read this for security reviews, procurement questions and self-hosting decisions.

This chapter describes Quasar **2026.10.15**.

### Hosted or self-hosted

Quasar is one product, deployed two ways:
- **Hosted:** a multi-tenant service, where each organization is a tenant.
- **Self-hosted:** on your own infrastructure, by default with a single tenant.

The choice is a configuration of the installation, not a different edition. Everything in this guide applies to both unless it says otherwise.

### What a tenant is

A **tenant** is one organization's walled-off space: its people, projects, documents and settings. Nothing belongs to two tenants, and a person signed into one tenant sees nothing of any other.

Above the tenants, the **operator** of an installation manages it from a separate console:
- instance settings, mail and sign-in;
- background jobs and backup status;
- the platform audit log;
- the product guide;
- on the hosted service, the tenants themselves.

Inside the application, an operator can look into a tenant only through a **"view as"** session. It is read-only, as a member the operator chooses, for at most an hour, marked with a banner, and recorded in both the tenant's and the platform's audit log.

**Where the hosted service runs:** in the European Union, on Amazon Web Services in Ireland. A self-hosted installation keeps its data wherever it runs.

### What an installation needs

- **The application**, a single container image. It serves the web app, the REST API and the MCP server.
- **The rendering worker**, from the same image. It renders each published documentation release once to PDF, Word, HTML and Markdown. It is required, and must see the same file storage as the application.
- **PostgreSQL.** All data lives in it.
- **File storage:** a local volume or any S3-compatible storage. Files are always served through the application or through short-lived signed links, never as public bucket addresses.
- **Optional:**
  - antivirus scanning with ClamAV, off until configured;
  - email over SMTP or Amazon SES, for deadline reminders and password resets.

### Tenant isolation

Isolation between tenants is enforced by the database itself, through **PostgreSQL row-level security**. It is enabled and forced on every table that holds a tenant's data.

- The application connects with a database role that cannot bypass it.
- Every request runs in its tenant's context.
- Filters written in the application's queries are defence in depth, not the boundary.
- Isolation is tested against a real PostgreSQL in every release.

### Signing in

An installation chooses its sign-in provider:
- **Quasar's own accounts:** password and second factor, with password reset by email.
- **An OpenID Connect provider:** your organization's single sign-on.

Who may enter is decided by the identity the provider asserts, never by an email address alone. A person reaches an organization by:
- an invitation;
- an existing identity;
- membership the provider vouches for.

Sessions are kept on the server, in a cookie that carries no personal data.

### Second factor and step-up

- **Methods.** An authenticator app (TOTP) or a security key. There are no SMS codes.
- **Policy.** An organization can require a second factor of every member, and new organizations start with it required. Administrators see who is enrolled, and can reset a member's factor; the reset is audited.
- **Step-up.** Sensitive actions ask for a fresh second factor, among them creating API keys, lowering data retention and exporting personal data.

### API keys

- A key acts with exactly its owner's permissions, never more.
- Keys are shown once, expire after 90 days by default, and can be revoked at once.
- A **read-only** key is enforced by the database: its transactions cannot write.
- Each key is rate-limited, so a runaway script slows down instead of degrading the service for others.

### Permissions

- **Organization roles:** Admin, Member and Viewer.
- **Project roles:** Project manager, Member and Viewer.
- **Divisions and teams** can adjust access, but the project has the final word.
- **Hidden versus refused.** A project someone may not see does not appear to exist. A refusal is given only where the thing is visible but the right is missing.

### Records

- **Tenant audit log:** administrative actions, sign-ins, sign-outs and failed sign-ins.
- **Event logs:** every change to issues, documents and sprints, with who made it and whether an agent acted for them.
- **Platform audit log:** every operator action.

### Files and delivered documents

- **Attachments and uploads** are size-limited and type-checked, and scanned when antivirus is configured. They are always offered as downloads, never displayed inline.
- **Exported documents** are self-contained:
  - they carry a strict content-security policy;
  - they never load anything from the network;
  - they refuse to deliver text marked internal.

### Data export, retention and erasure

- **Personal data export.** Every person can export their own data as JSON, for the rights of access and portability.
- **Retention.** Deleted items stay in a project's trash for a period the organization sets, from 7 to 365 days, then are purged.
- **Erasure.** Erasing a person anonymizes them in place, so histories stay consistent without naming them.
- **Leaving the hosted service.** An organization can be exported in full, then deleted after a grace period.

### How the software is built

- **Stack:** TypeScript, PostgreSQL and Docker.
- **Tests:**
  - 100% automated test coverage is the minimum for every change;
  - on top of it: mutation testing of critical logic, property-based tests, golden tests for money, and tenant-isolation tests on a real database.
- **Dependencies** are audited for known high-severity vulnerabilities before every release.
- **Releases** are numbered by date, `YYYY.MM.N`, and every running build shows its version and commit.

## Licensing and pricing

> Pricing and licensing for Quasar are still being defined as of October 2026: there is no public price list, plan structure or licence text yet. What is already settled is that Quasar is offered both as a hosted service and for self-hosting, from the same product. This chapter says what is decided, what is not, and how to ask for an offer. Read it before quoting any price or licence term: none should be inferred from elsewhere.

**Pricing and licensing are being defined.** As of October 2026, Quasar has no public price list, no published plan structure and no standard licence text. This chapter will be rewritten when they exist. Until then, no price or licence term should be inferred from anything else in this guide.

### What is already settled

- **Two ways to run it.** Quasar is offered as a hosted service and for self-hosting. Both are the same product, and the choice is a matter of configuration, not edition. See *Deployment, tenancy and security*.
- **Features are not hidden behind configuration today.** Every capability described in this guide is available in every installation of version 2026.10.15. Quasar has a mechanism to make features depend on a plan or a licence, and the plans that will use it are part of what is being defined.
- **Your data stays yours.** Every person can export their own data, and a whole organization can be exported in full. See *Deployment, tenancy and security*.
- **The hosted service runs in the European Union,** on Amazon Web Services in Ireland.

### What is still open

- prices, the unit they are charged by, and the billing currency;
- whether viewers, service accounts and AI agents count as users;
- trials, a free tier or a guided demo;
- backup commitments and service levels;
- the self-hosting licence: model, inclusions, support and updates;
- the data-processing agreement and contract terms.

### How to ask

Ask Nuzzo Dev Studio, which builds Quasar, for an offer that fits your organization: hosted or self-hosted, number of people, and the support you need. An offer made now states its own terms.

## Comparison with alternatives

> How Quasar 2026.10.15 compares with the kinds of tool teams usually weigh it against, as the market stood in October 2026: - established enterprise trackers; - developer-first trackers; - code-hosting platforms with built-in coding agents; - open-source self-hostable trackers. Most of them now offer an official MCP server, so MCP access alone no longer sets Quasar apart. What does: - a workflow that demands evidence from agents (verified plans, code that reached a branch, time measured and confirmed); - automatic attribution of agent work and safe retries; - delivery to clients in the same tool; - self-hosting of the same product. The chapter also states where the alternatives are stronger today. Read it when choosing between Quasar and another tracker.

This comparison describes Quasar **2026.10.15** and the market as it stood in **October 2026**. Other tools change quickly; check their current state before relying on a detail here.

### The short version

By late 2026, connecting an AI agent to a project tracker is no longer rare. Most established trackers offer an official MCP server, and the code-hosting platforms let you assign an issue directly to their own coding agent. **Quasar does not compete on "agents can reach it".** It competes on what happens when they do:
- **Evidence over trust.** The workflow can refuse to move an issue until the agent has recorded a verified plan, until its code has actually reached a branch, or until its time is logged. Quasar reads these facts itself; it does not take the agent's word.
- **Accountability by construction.** Every change carries who made it and whether an agent did, without anyone declaring it. An agent's working time is measured by Quasar's clock and becomes a cost only when a person confirms it.
- **Safe automation.** Every write can be retried without duplicating, every concurrent edit is detected, and every refusal explains the rule that refused it, in terms an agent can act on.
- **From plan to client in one tool.** Quotes priced from the work, documents accepted on an exact revision, documentation released as frozen versions in four formats, and public guides that people and AI assistants can read.
- **The same product hosted or on your servers.**

### Established enterprise trackers

The long-standing trackers used by large organizations, with large marketplaces of extensions.

**Where they are stronger today:**
- maturity and scale;
- integrations with almost everything;
- mobile apps;
- many interface languages;
- enterprise compliance programmes;
- migration paths from everything else.

By 2026 they also offer:
- official, hosted MCP servers;
- their own AI agents working inside the tracker;
- semantic search across their products.

**Where Quasar differs:**
- **Access is not policy.** Their MCP servers give an agent access to the tracker. The policy about what the agent must prove before work moves on is left to configuration and to people. In Quasar it is part of the workflow: a verified plan, code observed in the repository, measured time.
- **Hosting.** Their official MCP servers are typically cloud-only and hosted by the vendor. Quasar's MCP server is part of the product, hosted or self-hosted alike.
- **Client delivery** is a separate product or an extension there: quotes, revision-bound acceptance, documentation releases. In Quasar it is built in.
- **Shape.** Quasar is deliberately narrower: no marketplace, fewer integrations, and an interface in English only.

### Developer-first trackers

Fast, opinionated trackers favoured by product and engineering teams. By 2026 they ship an official remote MCP server, read-only access options and their own agent features.

**Where they are stronger today:**
- speed and polish of the interface;
- keyboard-driven use;
- a large user base;
- native integrations with code hosts and chat tools.

**Where Quasar differs:**
- **Opinions encoded in the workflow.** Quasar's workflow conditions can block a move on evidence: sections filled in, a plan verified against the files it examined, the code's position in the repository, time logged.
- **Safety for automation.** An idempotency key on every write, versions on every entity, read-only keys enforced by the database, and an agent mark on every change.
- **Beyond engineering.** Money and delivery are first-class: work logs at the rate in effect, per-project currency, quotes, and documentation releases.
- **Self-hosting** of the same product, where these tools are typically cloud-only.

### Code-hosting platforms with built-in agents

Platforms that host the repository and track issues next to it. By 2026 you can assign an issue directly to the platform's coding agent, which opens a branch and a pull request, and the platform's MCP server lets external agents in under the user's permissions.

**Where they are stronger today:**
- The issue, the code and the agent that writes it live in one place, with no integration to set up.
- Their agents run in the platform's own build environment.

**Where Quasar differs:**
- **Host-neutral.** Quasar observes GitHub, GitLab and Bitbucket Cloud alike, so planning does not depend on where the code lives.
- **Bring your own agent.** Quasar does not run a coding agent. It is the place where any agent — and the people supervising it — plan, record and are held to the same rules.
- **Observes, never writes.** Quasar never touches the repository: it reads where each issue's code is and proposes the git commands, rather than acting on the code.
- **A project's whole lifecycle.** Planning across many repositories and non-code work, schedules and Gantt, time and money, quotes, document review and releases.

### Open-source self-hostable trackers

Trackers that can be run on your own servers, with community or official MCP servers that also reach self-hosted instances.

**Where they are stronger today:**
- open-source licences;
- community extensions;
- wiki-style pages;
- broader integrations.

**Where Quasar differs:**
- **Isolation by the database.** Tenant isolation is enforced by row-level security and tested against a real database in every release.
- **An MCP server built into the product,** designed around workflow-sized tools and explanatory refusals rather than a wrapper over the REST API.
- **Agent accountability:** verified plans, measured work sessions and automatic agent marks.
- **Client delivery,** as above.

### When another tool is the better choice

- **You need a mobile app,** an interface in your language, or hundreds of ready-made integrations: an established tracker fits better today.
- **Your work is code in a single repository host,** and you want the platform's own agent to write it: the code host's built-in tracking may be enough.
- **You need an open-source licence:** Quasar is not open source.

Quasar is the better fit when AI agents do real work in your projects and you need to know, and to prove, what they did. It also fits when the same tool has to carry that work all the way to the client.

## Crucial points and objections

> For buyers and salespeople evaluating Quasar 2026.10.15. The chapter covers: - the three points that matter most; - the strongest proof: Quasar is built with itself, by AI agents working under its own workflow with one architect supervising, a young product and honest about it; - honest answers to the usual objections: - "our tracker already has MCP"; - "you are a small vendor"; - "English-only and desktop-only", with Italian and French next on the roadmap; - "no Slack or webhooks", which is true today; - "how do we migrate"; - "can we trust an agent with write access"; - "where is our data", answered with the hosted service in the EU, in Ireland; - "another tool to learn". Read it to prepare for or answer a sales conversation.

This chapter describes Quasar **2026.10.15**. Each answer below states what is true today, including where the answer is "not yet".

### The three points that matter

1. **Agents work under the same rules as people, and you can see what they did.** Every change records who made it and whether an agent did, without anyone declaring it.
2. **The workflow asks for evidence, not trust.** An issue can be held until its plan is verified, its code has reached a branch, and its time is logged. Quasar checks these itself.
3. **From plan to client in one tool.** Quotes, reviewed and accepted documents, frozen documentation releases and public guides come from the same project data.

### Built with itself

The strongest evidence for Quasar is how Quasar itself is built.

**Everything lives in Quasar.** Every piece of Quasar's own work is tracked in Quasar:
- every feature, bug and task;
- every plan made before the code was written;
- every architectural decision;
- every document, including this guide.

**Agents do the work, under its rules.** AI coding agents pick up the issues. They record a verified plan before writing code, move the work through the same workflow Quasar offers its customers, and have their working time measured by its clock. One architect supervises: decides what is built, reviews, and accepts.

**The workflow is tested on its own builders.** The workflow that demands evidence from agents is enforced on the agents that build Quasar. Every rule in it was learned on Quasar's own work first, and every limit described in this guide is met by its makers before anyone else.

**Measurable, and dated.** As of version 2026.10.15:
- more than 19,000 automated tests, at 100% coverage, run before a change is accepted;
- new versions ship days apart.

**Young, and honest about it.** Quasar is a young product built by a single architect with AI agents. It is less mature than trackers with years and large teams behind them, and it says so in this guide. What it has instead is a product whose every rule has been lived by its makers before being offered to anyone else.

**This guide is an example.** An agent wrote it from the project's own documents and decisions. A person reviewed it and accepted it as a release revision before it became public.

### "Our tracker already has an MCP server."

Most trackers have one by now. It gives an agent **access**. What the agent must prove before work moves on stays a matter of configuration and of people watching.

In Quasar that policy is part of the workflow:
- a plan verified against the files it examined;
- code Quasar has seen reach a branch in the repository;
- time measured by Quasar's own clock and confirmed by a person.

Around it:
- every change an agent makes is marked automatically;
- every write can be retried without duplicating;
- every refusal tells the agent which rule to satisfy.

See *Comparison with alternatives*.

### "You are a small vendor. What if you disappear?"

Your work does not depend on us being reachable:
- Quasar can run on your own infrastructure, the same product as the hosted service.
- An organization's data can be exported in full at any time.
- Documents and releases export to PDF, Word, HTML and Markdown, readable without Quasar.

### "The interface is English only, and desktop only."

**True today.** The interface was designed from the start to be translated: every word on screen comes from translation files, not from the code. English came first as the common language. Now that Quasar is reaching its market, the next steps on the roadmap are languages, starting with European ones, **Italian and French first**.

Content was never limited to English:
- documents can be written in any language, each marked with its own;
- built-in document templates already exist in English and Italian.

The interface is designed for desktop screens; there is no mobile app.

### "There is no Slack, no webhooks, no integrations."

**True.** Quasar has no chat integrations and does not call other systems when something changes.

What it has is a complete REST API and an MCP server: any script, CI job or AI agent can read and do everything a person can, under that person's permissions. Integrations are built on that today.

### "How do we migrate our existing issues?"

There is no ready-made importer from other trackers yet. Data can be brought in through the REST API, which accepts the same operations as the interface, safely retryable. An agent connected over MCP can also move work across item by item, following the project's rules.

### "Can we trust an agent with write access?"

You decide how much it can do, and you can always see what it did:
- **Its permissions are its person's.** A key acts only with its owner's permissions; a project the owner cannot see does not exist for the agent.
- **Read-only, enforced.** A read-only key is enforced by the database itself: it cannot write.
- **Nothing silent.** Every change is attributed to the key's owner and marked as an agent's.
- **Evidence first.** The workflow can hold work until the agent provides evidence.
- **Acceptance.** Quasar's agent contract tells agents to accept documents only on a person's word. To make it impossible, give the agent a key whose owner is not a project lead.
- **Time.** An agent's time becomes a cost only when a person confirms it.

### "Where is our data, and who can see it?"

- **The hosted service runs in the European Union,** on Amazon Web Services in Ireland.
- **Organizations cannot see each other.** Isolation is enforced by the database's row-level security, not by application code alone.
- **Operator access is limited and recorded.** Inside the application, the operator of the service can look into an organization only through a "view as" session: read-only, as a member it chooses, for at most an hour, marked with a banner, and recorded in your organization's audit log.
- **Self-hosting** puts your data wherever you run it.

### "It is another tool for the team to learn."

People use a conventional web interface, with a glossary and step-by-step guides inside the application.

The bigger difference is that **the agent can guide the person.** An agent connected to Quasar learns the project's rules on its own when it connects. It can then do the operations itself or walk a person through the interface step by step, whichever they prefer.

This guide is an example: it is written so an AI assistant can read it, find the relevant chapter from its summary, and answer a newcomer's questions.

## Frequently asked questions

> Short answers to the questions evaluators ask most about Quasar 2026.10.15, among them: - Can an agent do anything a person cannot? - Can it see other projects? - Which agents and clients work with it? - Does Quasar write to my repository? - Can I self-host? - How are tenants isolated? - Can I use my own single sign-on? - Is there a mobile app? - Which languages are supported? - Can documents be published publicly? - What happens to an agent's working time? - Can we leave and take our data? Read a question's section for the answer, and follow its pointer to the chapter that goes deeper.

Answers describe Quasar **2026.10.15**.

### Can an AI agent do anything a person cannot?

No. An agent connects with a person's API key (or a service account's) and acts with exactly those permissions, through the same services as the web app. Everything it does is recorded under that person and marked as done by an agent. See *Working with AI agents*.

### Can an agent see projects it should not?

No. A project the key's owner cannot see does not exist for the agent either: it is not listed, and asking for it answers "not found". A read-only key cannot write at all; the database refuses it.

### Which agents and tools work with Quasar?

- **Any client that speaks MCP over HTTP** with a bearer token. The in-app Help Center gives the exact setup for Claude Code, Codex, opencode and pi.
- **Any program** through the REST API.
- **ChatGPT and other assistants** can read a published guide, like this one, through its public MCP server or its OpenAPI description, with no key.

### Does Quasar write to my git repository?

No. It reads branches, commits, tags and pipeline results to show where each issue's code is. It never commits, merges, branches or tags. The one thing it creates is the webhook that tells it about new commits. For version branches and releases it proposes the exact git commands and checks afterwards that they happened.

### Which git hosts are supported?

GitHub, GitLab and Bitbucket Cloud, one repository per project.

### Can we run Quasar on our own infrastructure?

Yes. The same product runs self-hosted, by default with a single organization. It needs:
- the application and its rendering worker (one container image);
- PostgreSQL;
- file storage (a volume or S3-compatible);
- optionally, ClamAV and an SMTP or Amazon SES mail service.

See *Deployment, tenancy and security*.

### How is our data kept apart from other organizations'?

By PostgreSQL row-level security, enforced on every table that holds an organization's data. The application connects with a role that cannot bypass it, and the isolation is tested against a real database in every release.

### Can we sign in with our own identity provider?

Yes, any OpenID Connect provider, chosen per installation. Quasar can also manage its own accounts, with a password and a second factor.

### Is two-factor authentication supported?

Yes:
- **Methods:** an authenticator app or a security key; SMS is not offered.
- **Policy:** an organization can require it of everyone.
- **Step-up:** sensitive actions ask for a fresh second factor.

### Is there a mobile app?

No. The web interface is designed for desktop screens, 1,024 pixels wide and more.

### Which languages are supported?

The interface is in English today. It was designed to be translated, and the next languages on the roadmap are Italian and French, followed by other European languages. Documents can be written in any language, each with its own content language. Built-in document templates are available in English and Italian.

### Where is the hosted service's data?

In the European Union: the hosted service runs on Amazon Web Services in Ireland. A self-hosted installation keeps its data wherever you run it.

### Can we publish documentation publicly?

Yes. An organization administrator can make a published documentation release readable by anyone at its own address, without an account, three ways:
- **web pages**, with search and a site map;
- **a REST API**, with an OpenAPI description;
- **an MCP server** that AI assistants can connect to.

What is public is only what was accepted and published, and pausing it takes it offline at once.

### What happens to the time an agent spends?

Quasar measures it: the agent opens a work session when it starts a turn and closes it when it hands back, and Quasar's own clock stamps both. A session becomes a work log, with its cost, only when a person confirms it.

### Can an agent approve its own work?

Two things stand in the way.
- **The contract.** Quasar's agent contract tells every agent to accept a document or a release revision only on a person's explicit word. Every acceptance is recorded with whose key made it, and whether an agent acted.
- **The workflow.** It can require conditions an agent cannot fake:
  - a verified plan;
  - the code having actually reached a branch;
  - time logged.

To keep a key from accepting at all, give the agent a key whose owner is not a project lead, or a read-only key.

### Does Quasar send email?

Only for deadline reminders and password resets, through SMTP or Amazon SES. There are no email digests and no outbound webhooks.

### Is there AI inside Quasar?

Quasar does not run a model of its own. It is built so that your agents, whichever you choose, can work in it safely. Search is full-text, not semantic; where meaning matters, an agent reads document summaries and chooses.

### Can we export our data or leave?

- **Every person** can export their own data as JSON at any time.
- **A whole organization** can be exported in full, then deleted after a grace period.
- **Documents and releases** export to PDF, Word, HTML and Markdown.

### How do we know which version we are running?

Versions are numbered by date (`YYYY.MM.N`). The running version and its commit are shown in the application and available from the API.

## Glossary

> Plain-language definitions of the words Quasar uses, grouped by theme: work tracking (issue, epic, status, workflow, backlog, inbox, deadline), planning (sprint, story points, velocity, work kind), money and delivery (work log, quote, release, revision, acceptance), the asset library and artifacts, versions in git (version branch, hotfix, release tag), agents and access (agent, MCP, API key, service account, work session, pre-analysis), and the organization (tenant, operator, public publication, product guide). Read it to decode a term used elsewhere in this guide or in the product.

The words Quasar uses, as of version **2026.10.15**.

### Tracking work

| Word | Meaning |
| --- | --- |
| **Issue** | One unit of work: a feature, a bug, a task. Each has a readable key such as `ABC-00042`. |
| **Project** | A container for issues and documents. Projects can hold sub-projects. |
| **Epic** | An issue that groups related issues around a theme. Its progress is the progress of the issues under it. |
| **Story, Task, Bug, Sub-task** | The kinds of issue: something a user wants, work to be done, something broken, a small step inside one of these. |
| **Status** | Where an issue is now: Backlog, To do, In progress, Testing, In review, Done, Reopened. An organization can rename them. |
| **Workflow** | The rules for which status may follow which, and on what conditions. |
| **Resolution** | Why an issue is Done: Fixed, Won't fix, Duplicate, Cannot reproduce or Incomplete. |
| **Section** | A typed part of an issue, such as its pre-analysis, decisions or verification. |
| **Definition of Done** | A checklist an issue must satisfy before it is finished. |
| **Backlog** | Work not started yet. Different from *unplanned*, which is work in no sprint. |
| **Inbox** | A project's notes for requests nobody has decided on yet, later turned into issues or discarded. |
| **Deadline** | A dated fact from outside that may break something, such as a certificate expiry or a provider's change, with reminders before it falls due. |

### Planning

| Word | Meaning |
| --- | --- |
| **Sprint** | A fixed stretch of time that a set of issues is planned into. |
| **Story points** | A rough size for an issue: how big, not how many hours. |
| **Velocity** | How much delivery work sprints complete. Investigation, technical and management work are reported beside it, not in it. |
| **Work kind** | What an issue's work produces: delivery, investigation, technical or management. |
| **Board** | The card view of a sprint, one column per status. |
| **Critical path** | The chain of work whose delay delays the whole project, shown on the Gantt chart. |

### Time, money and delivery

| Word | Meaning |
| --- | --- |
| **Work log** | Time spent on an issue, at the hourly rate in effect when it was logged. |
| **Quote** | A priced offer for a client, built from issues and their estimates. Frozen once sent. |
| **Acceptance** | A person's approval of a document or a release revision. It binds to the exact text it was given on. |
| **Release** | A frozen set of documentation published in numbered revisions. |
| **Revision** | One version of a release, such as *Rev. 2*. Once published it never changes; changes go into the next revision. |
| **Summary** | A short text on every document and chapter saying what it covers, so a reader or an agent can judge it without opening it. |

### The library and artifacts

| Word | Meaning |
| --- | --- |
| **Asset** | One thing kept in a project's library, such as a logo or a screenshot, with all its files. |
| **Variant** | One file of an asset: a size, a theme, a language. |
| **Artifact** | Something a version delivers: a package, a binary, a container image or an archive. Immutable once uploaded. |
| **Withdrawal** | Taking an artifact out of use, with a reason. Permanent. |

### Versions in git

| Word | Meaning |
| --- | --- |
| **Version** | A release of a project, numbered as the project chooses. Quasar itself uses `YYYY.MM.N`. |
| **Version branch** | The git branch where one version's work is integrated while it is built. |
| **Release tag** | A git tag on exactly what was deployed for a version. |
| **Hotfix** | An urgent fix to what is already installed. It does not change the version number. |

### Agents and access

| Word | Meaning |
| --- | --- |
| **Agent** | An AI coding agent, or any program, working in Quasar through its API under a person's key. Its actions carry an **Agent** mark. |
| **MCP** | The Model Context Protocol, the way coding agents talk to tools such as Quasar. |
| **API key** | A credential starting with `qsk_` that lets a program act as its owner. It can be read-only. |
| **Service account** | A non-human member with its own keys, for CI and integrations. |
| **Work session** | The span of one agent turn, timed by Quasar's clock. It becomes a work log only when a person confirms it. |
| **Pre-analysis** | The plan an agent records before starting an issue, with the files it examined. It goes stale if those files change. |
| **Agent contract** | The versioned rules Quasar gives an agent about how to work. |
| **Step-up** | A fresh second-factor check before a sensitive action. |

### The organization

| Word | Meaning |
| --- | --- |
| **Tenant** | One organization's walled-off space in Quasar. Nothing in it is visible to any other. |
| **Division, Team** | Groupings of people and projects inside an organization, which can adjust access. |
| **Operator** | Whoever runs an installation of Quasar, from a console above the tenants. |
| **Public publication** | A published documentation release an organization has made readable by anyone, as pages, a REST API and an MCP server. |
| **Product guide** | Quasar's own documentation, served by every installation. This guide. |