Custom topic types with definable status workflows

LOGOS needs the ability to define custom topic types beyond a fixed platform set, each with its own status model, visual identity, and behavior.

Why It's Needed

Talkyard offers a fixed set of topic types: Discussion, Wiki, Question, Problem, Idea. These cover common forum patterns but don't map cleanly onto the specific kinds of things LOGOS needs to express. Working through how to categorize Talkyard limitation records and Chat Import Pipeline issues made this concrete — what was needed was something between Discussion and Problem: an immutable observed fact with no resolution workflow. That type doesn't exist. The workaround is using Problem and accepting that the status model doesn't quite fit.

The broader pattern: every domain has its own kinds of things with their own lifecycles. A general-purpose knowledge system shouldn't force those into a fixed type set.

The Requirement

Topic types in LOGOS are definable, not fixed. Each type specifies:

• Name and icon — visual identity in topic lists
• Status model — the set of valid statuses and their terminal/non-terminal nature
• Status labels — named to fit the domain, not generic (e.g. Accepted as a terminal state distinct from Done)
• Fields — optional additional structured fields relevant to the type
• Behavior — whether the type is editable after posting, whether replies change its state, etc.

The platform ships with sensible defaults (the types Talkyard already offers, roughly) but none are hardcoded.

Acceptance

A forum administrator can define a new topic type with a custom name, icon, and status workflow without code changes. Existing topics can be reclassified to the new type. Topics display their type visually in category listings.

Source

Discovered while structuring the Talkyard Limitations and Chat Import Pipeline categories — needed a topic type that conveyed "immutable observed fact" without implying an open/closed resolution model.

Cross-references

• Related: LOGOS → Talkyard Limitations → README (explains why limitations are not Problem type)
• Related: Chat Import Pipeline (where Problem type is used as the closest available fit)