Two Modes, Kept Deliberately Apart

The Workshop Has Two Kinds of Work in It

Open the repository and you find two sibling directories that do superficially the same thing — produce a video — and are structured completely differently.

Projects are one-offs. A project holds the data, the script, and the scene composition for one specific piece. It was designed once, for that piece, and it will never run again with different inputs because there are no different inputs.

Pipelines are repeatable production characters. A pipeline holds stages parameterized by a pointer, a locked format contract, and an index of what it has produced. It is designed to run many times, and every run is the same format applied to different material.

The obvious refactor is to collapse them: make the one-offs into pipelines with a single entry, or make pipelines a special case of projects. Neither has been done, and the reason is the interesting part.

Some Work Is Genuinely Singular

The two founding videos were bespoke. Their structure was chosen for what they were saying — this argument, this sequence, this ending — and none of those choices generalize, because there was never going to be a second piece making the same argument. Forcing them into a repeatable shape would not be a cleanup. It would be asserting a recurrence that does not exist, and the resulting abstraction would be fitted to a sample of one.

Meanwhile the series genuinely recurs, so its format is worth locking and its variation is worth confining to a pointer. That is a real distinction about the work, not about the code, and a codebase that flattens it is telling a lie about what it produces.

The Retroactive Recognition

There is a twist worth sitting with. The design document that established pipelines notes that the two bespoke videos were a repeatable format all along — one that nobody had recognized yet. With twenty sibling applications to showcase, "introduce an application" was always going to recur; it just had not recurred yet at the time they were built.

So the honest position is not "one-offs and pipelines are permanently different categories." It is that recurrence is discovered, not declared. You build concretely, and when the second instance arrives with its own real requirements, the shared shape becomes visible — and it is a much better shape than the one you would have guessed before you had two examples. Promotion at second use is the rule; pre-abstraction for a hypothetical second use is the thing being avoided.

Code

The same repository, two structures·text

projects/<slug>/          bespoke - designed once, for this piece
  project.py                THE data + the stages, together
  REJECTION-LOG.md          this piece's verdicts, committed
  deliverables/             approved snapshots, committed

pipelines/<name>/         repeatable - a production character
  pipeline.py               stages, parameterized by a pointer
  FORMAT.md                 the locked format contract
  EPISODES.md               one line per shipped run

# Note what the pipeline directory does NOT contain:
# any episode. The material lives outside the repository entirely.
# A project contains its own material; a pipeline never does.

Where the variation lives, in each mode·python

# PROJECT: the data IS the code. Changing the piece means editing this.
ROSTER = [
    {"name": "...", "tagline": "...", "shot": "..."},
    # the Nth entry costs one line here plus a re-render -
    # which is the founding rule, on the roster axis.
]


# PIPELINE: the data is fetched. Changing the episode means
# passing a different pointer - the code does not move at all.
def main(pointer: dict) -> None:
    material = dereference(pointer)     # <- the ONLY variation
    for stage in STAGES.values():
        stage(material)

# Same founding rule, moved one axis over:
#   project: the Nth roster entry costs one line of data
#   series:  the Nth episode costs one identifier

Exercise

Find two scripts or jobs in your work that look similar enough that someone has suggested merging them. For each, write down what would change if you ran it again next month: the inputs, or the shape? If both would change only in inputs, extract the shared pipeline. If either would change in structure, write down why merging them would have forced a false commonality.

Hint

The strongest signal is a proposed shared function that would need a boolean parameter to select behavior. That parameter is the two cases telling you they are structurally different, and every one you add afterward is the abstraction charging interest on a merge that should not have happened.