README

This category is where the LOGOS software gets defined.

Each topic here is a single requirement — a concrete, nameable thing that LOGOS must do or be. Requirements come from anywhere: a Talkyard limitation that LOGOS won't have, an integration constraint discovered in practice, a design decision made during planning, an idea that surfaced mid-conversation, or a user need that no existing tool handles well.

What a Requirement Topic Contains

• What it is — a clear statement of the capability or behavior required
• Why it's needed — the source: what situation, limitation, or insight generated it
• Acceptance — how you'd know it's satisfied
• Cross-references — links to related limitations, other requirements, or design discussions

What This Is Not

This is not a backlog or a task list. Requirements are not assigned to sprints or estimated. They are a definition of what LOGOS is — the accumulated understanding of what the software must be. Implementation planning happens elsewhere.

Topic Types

Two types are used in this category:

Idea — a candidate requirement that is not yet fully understood or validated. The need is real but the shape of the solution, the acceptance criteria, or the priority isn't clear yet. Ideas are open for discussion and refinement.

Problem — a requirement that is understood well enough to act on. It has a clear statement, a known source, and acceptance criteria. The status model maps as follows:

• New — captured and understood, but design thinking has not started
• Planned — design thinking has started, approach is taking shape
• Started — actively being designed or implemented
• Done — satisfied in the LOGOS software

An Idea becomes a Problem when it is understood well enough to define acceptance. A Problem marked Done is one LOGOS has built. A Problem still New is part of what remains to be built.