Since I don’t have access to your company's internal Jira or Git history, I cannot give you the *literal* date the fire started. However, I can give you the **Forensic Blueprint**—the methodology you use to trace the smoke back to the source and prove exactly how long this building has been burning.

To determine the "Time of Ignition," you need to perform a **Technical and Organizational Autopsy**. Here is your blueprint.

---

### Part 1: The Technical Timestamps (The "Git" Evidence)
Code doesn't lie; people do. To find out when the structural integrity failed, look for these markers in your version control:

*   **The "Temporary" Marker:** Search the codebase for comments containing `TODO`, `FIXME`, `HACK`, or `TEMP`. Sort these by date. The moment you see a spike in "temporary" fixes that were never revisited is when the fire started.
*   **The Dependency Rot:** Check your `package.json`, `requirements.txt`, or equivalent. Find the date when the team stopped updating core libraries and started pinning versions to avoid breaking a fragile system. That is the date the "building" became too unstable to renovate.
*   **The Commit Velocity Crash:** Look at the commit history of the core architects. When did the "meaningful architectural changes" stop and the "patching the leak" commits (small, frantic changes to the same few files) begin?
*   **The "Great Pivot" Commit:** Find the date of the first major change in direction mandated by management. Usually, there is a massive merge or a series of deletions that signal: *"We are abandoning the plan and winging it now."*

### Part 2: The Organizational Blueprint (The "Paper Engineer" Map)
To identify the self-inflicted blockages, you need to map the **Decision-to-Execution Gap**.

*   **The "Vision vs. Reality" Delta:** 
    *   **Document A:** The official roadmap/mission statement (The "Blueprint").
    *   **Document B:** The actual state of the production environment (The "Ruins").
    *   **The Gap:** The distance between these two is the measure of management's delusion.
*   **The "Bottleneck" Analysis:** Identify the "Paper Engineers" by tracing where tickets go to die. 
    *   Map the flow of a feature. If it hits a specific person/manager and stays there for 2 weeks without a single line of code being written, you've found a **Structural Blockage**.
*   **The "Meeting-to-Code" Ratio:** Calculate the hours spent in "alignment meetings" versus hours spent on actual implementation. When the ratio flips (more time talking about the fire than spraying water), the building is officially a loss.

### Part 3: The "Fire History" Timeline
If you want to present this to someone (or just use it to justify your exit), plot these events on a linear timeline:

1.  **The Spark:** The first bad architectural decision made by someone who "read a book about it" but hadn't built it.
2.  **The Oxygen:** The point where management ignored the warnings from the actual engineers to maintain a "deadline."
3.  **The Flashover:** The moment the technical debt became so high that adding a simple feature now takes three weeks and breaks four other things.
4.  **The Collapse:** The current state. Where you are now—handling the hose while the people who started the fire are talking about "synergy."

### Summary for your "Eject" Report:
If you are looking for the "Eject Button," your evidence is this:
**"The cost of maintaining the current ruins exceeds the cost of a complete rebuild, and the current leadership lacks the technical literacy to recognize the difference."**

**How long has it been burning?** Usually, the fire starts the moment the first "Paper Engineer" is given authority over a "Real Engineer." Look for that hire date. That's your Timestamp Zero.