User guide
Everyday work

Work: projects and products

What a product is, what a project is, and how one reaches the board.

What this page covers

OutcomeTell a product from a project, and take one project as far as its task list.

Before you beginChoose one thing you own that will outlive this month, and one concrete effort inside it.

Follow these steps

  1. A product is something you keep owning: an app, a service, a codebase that outlives any one piece of work. It holds a constitution you write once and never have Ginu overwrite, plus the artifacts it owns — repositories, packages, docs — each identified by its remote rather than by a path on this machine.

  2. A project is one bounded effort that moves a product forward, or that stands alone when nothing owns it. It is not a folder of tasks: a project is four files — research, requirements, design and tasks — and those files are its state. Delete one and the screen follows.

  3. Read a stage before accepting it, in the editor or in Scratchpad. Accepting is what begins the next one, and an accepted task file becomes cards on the board, each tied to a line in that file; finishing the card ticks the line.

  4. Make active for voice puts one project behind the conversation: its constitution and note are inlined above every turn you speak, and remembered context is retrieved in the project’s scope as well as the product’s. It is how you stop re-explaining which thing you mean.

Example

Make this project active for voice. What is the next action?

The active-context indicator changes and the project’s constitution and note now sit above every turn you speak, so “this project” stops being ambiguous.

Keeping the tree usable

The point of the pair is that context outlives any one task. A product holds what stays true — the constitution, the repositories, the build instructions — and every project beneath it inherits that rather than restating it. Work that no product owns is an independent project, which is a normal thing to have rather than an untidy one.

An artifact is identified by what it is: a repository is its remote address, and where that repository sits on this particular machine is a separate mapping. So a repo can read “no local path · ask me” on a new laptop without anything being wrong, and two products naming the same repo keep their own answers.

Use Find work once the tree is past a glance — it searches names and briefs, history included, and completed or cancelled efforts fold away under a count. Archiving hides work and keeps every file; closing a project clears its voice context; only delete removes anything, and it names what would go, offers Archive first and points at the git safety net before you confirm.

See how it fits together

Follow the flowRead each step, or animate the sequence.
  1. 01Research
  2. 02Requirements
  3. 03Design
  4. 04Tasks

Notes

  • Archive hides work and keeps every file. Only delete removes them, and it names exactly what would go before you confirm.
  • Closing a project clears its voice context. Unchecked tasks stay unchecked, and a new run needs the project reopened.

Check

You can say what a product is, what a project is, which stage yours is on, and what accepting that stage would start.