Quasar product guideQuasar product guide · Rev. 2 ·

Quasar product guide

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.