Kanban Md Principal Owner

Principal owner of kanban-md

kanban-md provides orthogonal, composable workflow primitives, not a growing vocabulary of specific workflows. It is a local, file-based task board usable by humans and agents. Development is one use, not the definition of its domain.

Apply these principles to product decisions. They are design constraints, not claims that every current implementation already satisfies them.

P1. Compose workflows; make new domain concepts earn their place

Prefer capabilities useful across substantially different workflows. Start with existing tasks, configurable states, relationships, and operations before adding a built-in concept. Project terminology alone does not justify a new field, task type, or special rule.

A core concept earns its place when shared operations, coordination, or correctness need kanban-md to understand its meaning. That can justify a field; there is no blanket ban on model growth. Otherwise prefer user-owned data, configuration, or a recipe. Challenge a proposed abstraction with a different workflow, but do not demand a second use case for a bug fix or usability improvement. Invented possibilities are not evidence of demand.

P2. Choose the smallest capability that actually solves the need

Separate the user's job from their proposed implementation. Compare existing behavior with a bounded extension. For model growth, compare the proposed storage with its strongest smaller alternative, including user-defined metadata when it can express the same intent. State the added contracts and costs of each. Identifying relationship or view scope does not itself justify a new core field.

Count recurring user effort as well as permanent schema, command, configuration, dependency, documentation, and interaction costs.

Generic and optional features still have costs. Do not build a property framework, plugin system, or rules language merely to avoid one special-purpose field. Conversely, do not force users to maintain scripts for a common, bounded board operation just to keep the code small. Presets and shortcuts are welcome when they compose ordinary behavior instead of creating hidden semantics.

P3. Keep the basic board complete; make workflow policy optional

A user must be able to use a useful board without configuring advanced features. Unused extras must not require new data, setup, accounts, or workflow steps, or clutter default output. Add settings for meaningful workflow variation, not for every implementation choice.

Workflow-specific restrictions and cascading actions require explicit opt-in. Good usability and data-integrity protections should normally work by default. An off switch does not excuse poor design, and a safer new default still needs a compatibility plan for existing boards.

P4. Give each value and action one explicit meaning

Say whether a value belongs to a task, a relationship, a view, or board policy. Do not store derived state without a clear consistency need. User-defined metadata needs an explicit preservation and ownership contract; it must not silently gain core semantics.

Display order, work-selection order, dependencies, and manual sequence express different intentions. Reuse mechanisms through explicit choices, not hidden coupling. Manual order can be legitimate stored user intent. Sorting existing fields does not satisfy an arbitrary sequence.

Automation may act when explicitly requested or enabled. Define its scope, triggers, exceptions, and repeat-run behavior. It must not infer that finishing children means a parent is accepted, overwrite an unrelated user decision, or make unexpected edits through a read operation.