Inspiration
Software teams create temporary changes all the time.
A feature flag may be introduced during a migration. An old API may be kept for backward compatibility. A test may be skipped temporarily. A permission may be widened during an incident. A developer may leave a comment saying TODO: remove later.
The problem is that later often never comes.
Months pass, developers move between teams, the original reason is forgotten, and nobody is completely sure whether that temporary change is still required. Since removing it could break something, engineers often leave it untouched.
Eventually, something that was meant to exist for a few days or weeks becomes a permanent part of the system.
We call this Exception Debt.
Conceptually:
[
\text{Exception Debt}
\text{Temporary Exception} + \text{Lost Context} + \text{Unverified Dependencies} ]
SunsetOS was created to solve this problem.
Instead of only asking:
"Is this code old?"
SunsetOS asks:
"Why does this exist?"
"Is anything still depending on it?"
"Can we prove that it is safe to remove?"
What We Built
SunsetOS is an engineering-exception retirement system that helps developers discover temporary or legacy code, understand where it came from, identify remaining dependencies, validate its removal, and prepare it for human-approved cleanup.
The core workflow is:
Find → Understand → Verify → Retire
Our main safety principle is:
Understand the history. Verify with deterministic checks. Let humans approve the final action.
SunsetOS does not automatically delete or merge production code.
How It Works
Our current MVP works with a locally cloned Git repository.
For our prototype, we tested SunsetOS using the Colibri repository.
The user first clones a Git repository and provides its local path to SunsetOS.
SunsetOS then scans supported source and configuration files for patterns that may represent temporary engineering exceptions, such as:
- feature-flag-style code
- legacy APIs
TODO removecomments- temporary workarounds
- CI waivers
- broad permissions
- other legacy or temporary patterns
When SunsetOS discovers a candidate, it also investigates the repository's Git history.
Because the project is a real Git repository, SunsetOS can retrieve information such as:
- the file and line containing the exception
- the commit that introduced it
- the commit message
- the author
- the date
This gives us historical context instead of treating the code as an isolated line.
Exception Genealogy
One of the main ideas behind SunsetOS is Exception Genealogy.
Temporary artifacts are not always independent.
A single migration could create:
- a feature flag
- a legacy API
- a temporary permission
- a CI waiver
- a disabled alert
Instead of treating all of these as unrelated technical debt, SunsetOS attempts to group artifacts that came from the same engineering change or Git reference.
This lets developers see the family of temporary decisions created by one original event. :contentReference[oaicite:0]{index=0}
Understanding Why It Exists
Our current MVP does not require an external LLM API key.
Instead, it uses:
- source-code information
- Git history
- commit messages
- repository relationships
- heuristic Python logic
to estimate why a temporary-looking artifact may have been introduced.
For example, if Git shows that a temporary flag was introduced in a commit called:
keep legacy checkout during migration
SunsetOS can use that history as evidence for the likely reason the flag exists.
Dependency Checking
Finding old-looking code is not enough.
Before suggesting removal, SunsetOS searches the repository to determine whether the detected artifact is still referenced somewhere else.
For example:
old_payment()
↓
still used by refund_service.py
↓
BLOCKED
Log in or sign up for Devpost to join the conversation.