Metadata-Version: 2.4
Name: finalfinal
Version: 1.0.0
Summary: FinalFinal™ is a file versioning system that encodes the project history directly into the filename, where it obviously belongs.
Keywords: filesystem,version control
Author: tlanguebien
Author-email: tlanguebien <tlanguebien@gmail.com>
License-Expression: MIT
License-File: LICENSE
Requires-Dist: reportlab
Requires-Python: >=3.9
Project-URL: Homepage, https://github.com/tristanlanguebien/finalfinal
Description-Content-Type: text/markdown

# FinalFinal™
### *Where Done Is Just Another Iteration.*

**FinalFinal™** is a file versioning system that encodes the project history directly into the filename, where it obviously belongs.
No Git, no SVN: **The filename is the changelog.**

## Use Case

In the age of deliverable-oriented agility, versioning alone is no longer enough. You need to *tell a story*. With FinalFinal™, every file becomes a compressed roadmap, a monument to the iterative process:

```
myfile_NEW_forProducers_minor-editsV2_FINAL-MostlyApproved.pdf
```

Each suffix is a chapter:

| Suffix | What it communicates |
|---|---|
| `NEW` | Ambition and optimism |
| `forProducers` | Illusion of governance |
| `minor-editsV2` | Resilience in the face of client feedback |
| `FINAL` | The conclusion of a production cycle (Provisional) |
| `MostlyApproved` | Aknowledges endless possibilities |

Every additional suffix reinforces collective confidence. If you have reached `final-v3-def-ok2`, you know the project is moving forward.

## Features

### Context-Driven Incrementation

`wip`, `retake`, `fix`, `done`, and `final` are handled as distinct increment types, each drawing from a curated pool of suffixes. FinalFinal™ helps you write the perfect narrative for your file, one version at a time.

### Certainty Levels

Are you unsure about your changes? Quietly confident? Dangerously overcommitted? FinalFinal™'s collection of carefully engineered affixes lets you compose version names with genuine emotional nuance:

- Low certainty: `report_probably-fixed.docx`, `brief sortOfDone.pdf`
- High certainty: `contract_100%_DEFINITIVE.docx`

### Reset

At some point, your filename will be ungodly long. This is not a flaw, just a sign that the project has lived.

The `reset` feature archives everything into a tidy `_OLD` folder (or `BEFORE_THE_INCIDENT`, if you prefer) and starts you fresh with one of our curated restart suffixes. You may then begin making the same mistakes again.

### PDF Export

At some point, someone will ask for a changelog. `to_pdf` generates a professional PDF documenting every version of your file, sorted by filename length (the closest available proxy for chronological order), annotated with modification descriptions such as:

> *"At 2024-11-04 at 14:32:17, someone clicked Save. We'll count that as work."*

Send it by email. Your inbox becomes your audit trail. This is fine.

## Technical Architecture

FinalFinal™ is powered by our proprietary **Recursive Semantic Drift™** engine, which enables:

- **Unlimited suffix stacking**: no enforced ceiling = endless possibilities.
- **Emotional and certitude encoding**: affixes such as `maybe`, `definitely`, `god-knows`, and `not-my-problem-anymore` allow for nuanced sentiment to be embedded directly in the file path.
- **Multiple coexisting final versions**: because sometimes the client validates two things on the same afternoon.

### Compatibility

FinalFinal™ is fully compatible with all modern file distribution infrastructure:

- 📧 Email (recommended)
- 💾 USB drives
- ☁️ Google Drive
- 🗂️ Network Shares named `\\PROD-FINAL\FINAL`

## Security & Compliance

FinalFinal™ is compliant with the following standards:

- **ISO-Good-Enough** (validated by nobody in particular)
- **Internally Ratified in a Meeting** (see the invite calendar for proof)
- **I.W.O.M.C.** (It Works On My Computer, the gold standard of pre-delivery testing)

> [!CAUTION]
> FinalFinal™ does not implement access control, version locking, encryption, or conflict resolution. These are considered premium concerns for a future definitive edition of FinalFinal™.

## Client Testimonials

> *"Since adopting `Budget_2025_v4_final_FINAL_ok2_USETHIS.xlsx`, we have reduced version conflicts by 0% but our perceived strategic alignment has increased by 300%."*
>
> -- A multinational corporation


> *"We spent a long time choosing between Git and FinalFinal™. What ultimately convinced us to go with FinalFinal™ was the price."*
>
> -- A cash-strapped CEO

> *"Before FinalFinal™, I wasn't versioning my files at all. Now I am. Sometimes I wonder if things were better before."*
>
> -- A weekend entrepreneur


## Roadmap

- **PowerPoint changelog export**: Following the overwhelming success of the PDF exporter and numerous requests from the field, our team is working tirelessly to deliver changelog exports in `.pptx` format. This will allow version history to be presented to the team with full slide transitions.

- **Variations**: The introduction of a branching concept. Functionally similar to Git branches, but implemented via subfolders for a better user experience.


## FAQ

**Why doesn't FinalFinal™ use commit messages?**

The name speaks for itself. For additional detail, send the file by email to your colleagues or clients. Your inbox *becomes* your changelog. By CC-ing the entire team on each send, you can be confident that everyone is up to date.

**Why can't I use `increment()` on a file that hasn't gone through `track()` first?**

On any given project, it would be unreasonable to version *every* file. Test files, throwaway scripts, files you are absolutely certain are already in their definitive final form from the first attempt: these do not require tracking.

**What if two people modify the file at the same time?**

This is called a *collaborative version event*. Both versions are valid. The longer filename wins.


## Installation & Deployment

Download the source code and unzip into your project directory. FinalFinal is supported by all modern deployment systems (dropbox, google drive, wetransfer...)

Alternatively, you can use pip or uv, even if it isn't frankly the spirit of the thing.

```bash
uv add finalfinal
pip install finalfinal
```

## Quick Start

The first step is to track the file.

> [!WARNING]
> When tracking a file, a metadata file ``important_notes_DONT_DELETE.docx`` will be created. 
> Do not ask for a more robust system: we already wrote DONT_DELETE in uppercase, YOU are responsible if the versioning framework breaks.

```bash
finalfinal --path brief.txt --track
>>> "brief START.txt"
```

Once the file is tracked, you can start using the increment feature.

```bash
finalfinal --path brief.txt --increment
>>> "brief START-updated.txt"
```

You can adjust the suffix by providing an `increment_type`, and nuance emotional feedback thanks to the `certainty_level` option.

```bash
# Available increment types are: wip, done, retake, fix, final. Defaults to wip
finalfinal --path brief.txt --increment --increment_type done --certainty_level 0
>>> "brief START-updated-Not_Far_From_Decent.txt"
```

The default certainty level is 1. Below 1 means "unsure", above 1 means "reckless confidence".

```bash
finalfinal --path brief.txt --increment --increment_type final --certainty_level 99
>>> "brief START-updated-Not_Far_From_Decent-ABSOLUTELYDEFINITIVE.txt"
```

Keep everyone up to date thanks to the PDF Export feature.

```bash
finalfinal --path brief.txt --export_pdf
>>> "brief_changelog.pdf"
```

> FinalFinal™ Changelog  
> File: brief.txt  
> Generated: 2026-06-14 at 11:48:08  
> The following represents the complete audit trail of this file. It should not be used in a court of law.  
> 
> Version 1: brief START.txt  
> A human being interacted with this file on 2026-06-14 at 11:36:34. Motivation: unknown.
> 
> Version 2: brief START-updated.txt  
> This version exists because someone, somewhere, was not satisfied with the previous one.
> 
> Version 3: brief START-updated-Not_Far_From_Decent.txt  
> The file was improved, allegedly, on 2026-06-14 at 11:46:36.
> 
> Version 4: brief START-updated-Not_Far_From_Decent-ABSOLUTELYDEFINITIVE.txt  
> Edits were performed. Whether they were improvements is a matter of perspective.

When the filename has grown to a length that violates several international conventions, it is time to reset (the metadata file is preserved. It has seen too much to be discarded.)

```bash
finalfinal --path brief.txt --reset
>>> brief-NEW_LEAF.txt
```

## Contributing

Send me your ideas on Discord, i'll consider implementing them.

---

<div align="center">

**FinalFinal™** - *Because the alternative is learning to use a real version control system.*

*© FinalFinal™ Industries. All versions reserved. None of them final.*

</div>
