Import an existing codebase

Not every product starts from nothing. If the code already exists, Taiga can read the repository and draft the product’s documents from it, rather than asking you to describe a system you have already built.

Starting an import

Choose Import codebase when you create the product. The choice is made at creation: a product started from scratch does not offer the import later.

A linked repository is the prerequisite. There is nothing to analyze without one, and linking it is what the new product asks you for first.

An imported product’s Discovery runs through that import in the place where a product started from scratch runs through the conversation. Nothing asks you to describe the system: you point Taiga at the repository, start the analysis, and the specification arrives from the code.

What happens

Importing is one decision. Everything after it runs by itself, and you can leave the page.

Taiga reads the repository and derives the full document set from it: what the system is, how it is structured, how data moves, what the security posture and risks look like. Each document is derived directly from the code, cites the files it was derived from, and the citations are checked against the repository before anything is kept.

When it finishes, those documents are the product’s documents. Nothing is rewritten or paraphrased afterward: what you read is what was found, with the evidence attached.

Three more things then run on their own, and the Initiatives page names each one as it happens. The scanners sweep the repository for findings, the document assessment compares it against your published policies, and the first initiatives are planned from all of it. Planning waits for the other two deliberately: an initiative cites the findings and policy violations it explains, and it can only cite what has already been recorded. You do not have to sit and watch: when you finish Discovery, an inbox item asks you to review the initiatives.

A stage that cannot run says so without being an error. A product with no connected repository has nothing to scan, and an organization that publishes no policies has nothing to be assessed against.

Review before you plan

An imported specification is inferred from code, and inference is where this path differs from Discovery.

Code shows what a system does. It does not show what it was for, which constraints were deliberate, or which parts are known to be wrong and already scheduled for replacement. Some of what you read will be an accurate description of an accident.

Read the specification first. It frames everything else, so a wrong assumption there is one you will meet repeatedly.

Three things worth checking specifically:

• Purpose. Does the stated vision match why the system exists, or only what it currently does?
• Deliberate versus incidental. A pattern that appears everywhere may be a standard or may be a habit nobody has revisited.
• Known problems. Anything you already intend to change will have been read as intent. Record that it is wrong, or agents will preserve it.

When something reads wrong

The documents are Taiga’s record of the code, and they are not edited by hand: they stay true by being re-derived from the repository as it changes, and an edit would be overwritten by the next refresh.

What you can do instead depends on what kind of wrong it is.

If the code is what is wrong — the document accurately describes something you intend to change — build the change. The documents follow the code, so fixing the code fixes the record.

If it is standing truth about how to work with this system rather than a description of it, “the legacy /auth module is scheduled for replacement, do not extend it”, put it in the product’s instructions: they are read by everything, every time, while a document is read when it is relevant.

If the analysis itself misread the code, refresh that one document rather than re-running the import: open it and choose Refresh this document. Taiga re-derives it together with the documents it is built on, so a document early in the chain comes back quickly and one near the end costs most of a full run. If it keeps misreading, that is a bug worth telling us about.

After the import

Finishing Discovery takes you to the Initiatives page, which is what the import was for.

The first initiatives are the work that no single fix covers. Each one is a missing capability, such as central audit logging or a shared way to manage secrets, that explains several findings or closes a gap against your policies; the foundation for building and testing changes safely, where the repository does not have one yet; or replacing or working around a dependency whose vulnerability has no fixed version to upgrade to. When the linked repository can be read, the planner checks it before naming a capability as missing, so a gap the code has already closed is not proposed. If the repository cannot be read, for example because its credentials have expired, the first backlog is planned from the documents alone. New features are not in this first set, because nothing has been asked for yet: add an initiative with your own prompt when you want one. A gap against your policies is planned as the capability it points to, even when it is the only one under its control. An individual finding that Maintaining can fix in one click is left out of this first set, unless another initiative builds on it or it is all there is to plan: when you choose to fix it there, that raises an initiative of its own. There is no set number: a repository in good shape gets a short list.

It is yours to change: edit an initiative, add one, or delete one. Nothing that was generated is final. To get more, add an initiative and leave both the title and the description empty: Taiga suggests the next one, starting from the most urgent finding or policy violation that no initiative covers yet.

From here the product behaves like any other, and the documents keep following the code: after a push to the product’s integration branch, and after built work is merged, the record refreshes from the repository (see product documents).