Skip to main content

Components

Components represent product areas such as Checkout, Billing, Auth, or Search. They are used to organize specs 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 spec?
  • 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.

Errors​

Tiden attributes runtime errors to components from the event's component tag, test file paths, and each component's runtime paths. See How errors get a component.

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 specs and tests that reference them.

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

Component references​

Specs 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.