Bring an existing codebase into Taiga

Start from the system you have

A fictional equipment request service already exists. The team wants to maintain it with Taiga while preserving its working integrations.

Choose Import codebase when creating the product. Link the repository and start analysis. This path uses repository analysis in place of the new-product conversation. A product created from scratch does not add this import path later.

Confirm repository access and the branch Taiga should work against. Add standing constraints at the appropriate context level. For this example, state that the existing employee identity integration must remain in use.

Review the inferred specification first

Taiga derives product documents from the code and includes repository citations. Those citations help you check the interpretation. They do not establish the business intent behind every existing pattern.

Inspect three things in the specification:

• Purpose: Does the described goal match why the service exists?
• Constraints: Which patterns are deliberate requirements?
• Known defects: Which current behaviors should change?

The equipment service contains a legacy authorization module. A document may accurately report its use. That does not mean the team should extend it.

Open a cited file and compare the relevant behavior with the claim. Record any limitation in the available evidence, such as configuration or operational behavior outside the repository.

Choose the correct correction

Imported documents follow the code. Do not treat them as manually maintained descriptions of a future system. A document refresh also re-derives the documents it depends on. Refreshing a later document can therefore require more work.

For the legacy module, an instruction could say: “Do not add new callers to the legacy authorization module. Use the approved replacement interface for new work.” Verify that the interface exists and name its actual repository location.

Assess the first initiatives

The import workflow also runs repository scans, assessment against published policies, and initial initiative planning. A stage without its prerequisite can be skipped with an explanation. Planning uses the findings and policy assessment that are available.

Review the proposed gaps against the repository. The initial initiatives address missing capabilities, foundations, or relevant unresolved dependency problems. They are not a list of new features that nobody requested.

Keep a useful existing capability. Reject or correct a proposal that would rebuild it unnecessarily. Add a separate initiative for a new business requirement.

Preserve an evidence-based starting point

Finish Discovery and review the initiative proposals. Confirm the environment and delivery responsibilities before detailed planning. Keep imports, code changes, and product instructions consistent as work proceeds.

The outcome is an understood starting point and an editable backlog. It is not a declaration that all existing behavior is correct. Continue with initiative planning.