Skip to main content

Components

Components represent product areas such as Checkout, Billing, Auth, or Search. They are used to organize requirements and tests and to break down quality gate risk.

When to create components​

Create components for durable product areas that help answer:

  • Which part of the product owns this requirement?
  • Which tests cover this area?
  • Which area is blocking a release?
  • Which errors or quality risks are concentrated together?

Avoid using components for one-off tags or temporary workstreams. Use branches or tags for temporary grouping.

Branch behavior​

Components participate in branch copy-on-write behavior:

  • New components on a branch are branch-local.
  • Editing a main component from a branch creates a branch copy.
  • Deleting a main component from a branch creates a deletion marker.
  • Merging applies reviewed component changes before requirements and tests that reference them.

Known gap: component history is not yet symmetric with requirement and test history.

Component references​

Requirements and tests reference main component identities. When a component is edited on a branch, Tiden resolves references so branch views still show the branch-specific component name.