Projects
What a project is in Zuse Bifrost, the key that prefixes every reference in it, its lifecycle statuses and health, the client it is done for, and the pages that manage them.
A project is one client engagement from discovery to maintenance: the container every component, environment, epic, story, requirement, test, release and incident lives under. The registry is where projects are created and shaped, the overview is each project's home once it is open, and the clients page is where the organisations they are done for are kept. Everything downstream reads this record, so these pages come first.
The pieces
| Piece | What it is |
|---|---|
| Project | One engagement, with a key such as CRM that prefixes every reference inside it (CRM-142), a lifecycle status, a methodology and four leads. |
| Client | The organisation a project is done for. A project names its client, so the client comes first; a client with projects is archived, never deleted. |
| Key | Two to six upper-case letters and digits, unique across everything the team ever had. It freezes the moment an artefact is numbered under the project. |
| Status | Where the project is in its lifecycle: discovery, planning, in development, in testing, live, maintenance, on hold or archived. |
| Health | On track, at risk, off track or not assessed, computed from the record as the modules that feed it land. |
| Visibility | Whole team, or members only. A client guest always sees a project through a membership row, whatever its visibility. |
| Component | One application the project is made of: the web app, the API, a mobile app, a service, with a slug such as web that its versions carry, a kind, a tech stack and an owner. |
| Environment | One place the project runs, from a developer's machine to production: its kind, the component it runs, its addresses, the branch deployed there, the health the last check found and whether a change freeze is in force. |
| Stakeholder | A person the project answers to, with or without an account: the client's sponsor, product owner and approvers, Zuse's own leads, third parties, each with a side, a role, a weight and the approvals that name them. |
| Persona | An archetypal user the project is built for, sketched with goals, frustrations and habits: the "as a …" of every story and the actor of every use case. |
| Glossary term | A word the project agrees on, with one definition, the other names it goes by, the terms it leans on and a review status; the project's own language, read by every story, requirement and test. |
| Data entity | A thing the project keeps records of, with its fields (type, flags, validation, example), its component, its owner, whether it holds personal data and how long it is kept; the data dictionary the contracts and designs are read against. |
| Design reference | A link the project keeps to one of its designs: a Figma file, a wireframe, a prototype, a screenshot, an API contract, a diagram or a document, attached to the whole project or to one component, with its version and the notes that say what to look at. |
| Repository | A Git repository the project's code lives in: its provider, owner and name, the branch releases are cut from, whether it is private and the component it builds; registered by hand now, connected to Git hosting later, and never shown to a client guest. |
| Setup | The intake wizard: the record built step by step from a client, a name and a paragraph, with presets for the house components and the standard environments, resumable from the sidebar until it is finished. |
| Settings | The project's knobs: sprint length and working days, timezone, estimation unit and scale, workflow flags, whether guests comment and Heimdall assists, the Telegram group, business hours. Only the keys somebody changed are stored; the rest follow the workspace defaults. |
A paragraph is enough
A project needs a client, a name and a key to exist, and a description to be useful. From that paragraph Heimdall can draft the components, environments, personas, glossary, entities and epics as the intake proceeds, and the registry grows into the record every later phase reads.
Pages
The registry
Every project you may see, with its filters, the editor, the status control, archiving, restoring, deleting and each project's history.
The intake wizard
Start a project from a client, a name and a paragraph, then add its components, environments, stakeholders and personas step by step, leaving and resuming at will.
The project overview
Open a project from the selector, the registry or a Heimdall button, and read its lifecycle, client, dates, leads, budget and latest activity in one place.
Components
Write down what the project is made of: each application with its slug, kind, tech stack and owner; archive the ones that are retired.
Environments
Register where the project runs, from development to production, with addresses, branch and flags; watch their health and freeze changes before a sensitive window.
Stakeholders
Record who the project answers to: each person's side, role and weight, the approvals that name them, and the account they decide from.
Personas
Sketch who the project is built for: named users with goals, frustrations, habits, proficiency and devices, for every story to be written for.
Glossary
Write down the words the project agrees on: one definition each, the other names, the related terms, and a review that decides when the client sees them.
Data dictionary
Write down what the project keeps records of, field by field: types, flags, validation, examples, owners, personal data and retention.
Design references
Link the designs the project is built from, Figma files to API contracts, attached to the project or one component, with the version that is current.
Repositories
Register where the code lives: each Git repository with its provider, default branch and the component it builds; set one aside when the team stops using it.
Project settings
Tune the project once: sprints, working days, timezone, estimation, workflow flags, guests, Heimdall and alerts; archive or delete it from the danger zone.
Clients
The organisations your team does projects for: add one, keep its contacts and status, archive it when it goes quiet.
Who may do what
| Action | Permission |
|---|---|
| See the registry | project:view-any, which every default role carries |
| Create a project | project:create, or owning the team |
| Edit, move or archive a project | project:update, through a project role or the team role |
| Delete a project | project:delete |
| See, add, change or delete components | component:view-any, component:create, component:update, component:delete |
| See, add, change or delete environments | environment:view-any, environment:create, environment:update, environment:delete; a guest sees UAT and production only |
| Freeze an environment | environment:freeze |
| See, add, change or remove stakeholders | stakeholder:view-any, stakeholder:create, stakeholder:update, stakeholder:delete; a guest sees them without contact details, ratings and notes |
| See, add, change or delete personas | persona:view-any, persona:create, persona:update, persona:delete; a guest sees them |
| See, add, change, move or delete glossary terms | glossary:view-any, glossary:create, glossary:update, glossary:delete; a guest sees the approved terms |
| See, add, change, move or delete data entities | data-entity:view-any, data-entity:create, data-entity:update, data-entity:delete; a guest sees the approved entities |
| See, add, change or delete design references | design-reference:view-any, design-reference:create, design-reference:update, design-reference:delete; a guest sees them |
| See, register, change, disconnect or delete repositories | repository:view-any, repository:create, repository:update, repository:delete; a guest is refused |
| Open and save the project settings | project:update; reading them over the API takes project:view, staff only |
| See the clients | client:view-any; a guest sees the clients of their projects |
| Add or change a client | client:create, client:update |
| Delete a client | client:delete, and no project may name it |
Related
- Status reference — every project, health and client status
- Members and guests — inviting a client's stakeholder as a guest of one project
- Projects API, Clients API, Components API, Environments API, Stakeholders API, Personas API, Glossary API, Data Entities API, Design References API, Repositories API and Project Settings API
project.*,client.*,component.*,environment.*,stakeholder.*,persona.*,glossary_term.*,data_entity.*,design_reference.*andrepository.*webhook events
How is this guide?
Last updated on
Webhooks
Register an endpoint that receives signed event payloads, pick its events, rotate its secret, pause or test it, and read and replay the delivery log.
The Registry
The Projects page: every project you may see with its filters, starting one in the intake wizard, editing it, moving its status, archiving, restoring and deleting it, and reading its history.