Linux, Python, vim, git & nix LPvgn Short Stack
Future-proof your skills and escape the tech hamster wheel with Linux, Python, vim & git — now with nix (LPvgn), an AI stack to resist obsolescence. Follow along as I build next generation AI/SEO tools for porting Jupyter Notebooks to FastHTML / HTMX Web apps using the Pipulate free AI SEO software.

The Workflow Factory: A Case Study in Emergent Modularity

The idea of moving from numbered steps to named ones felt promising, but seeing it work was a true breakthrough. Realizing I could arbitrarily re-order the steps list and the HTMX chain reaction would just follow was a ‘success assured’ moment. It confirmed that the system’s architecture was finally robust enough to become a true workflow factory—a platform where I could transplant entire bundles of functionality, glue them together, and just touch up the seams, drastically accelerating how new applications are built.

Setting the Stage: Context for the Curious Book Reader

This entry captures a pivotal moment in the development of Pipulate, a custom-built platform designed for creating flexible, chain-reaction style data processing workflows. At its core, Pipulate allows developers to assemble complex tasks from smaller, reusable steps. The central concept being explored here is the evolution from a rigid, numbered-step system to a far more modular “workflow factory” paradigm. This shift hinges on a key architectural insight: decoupling the display order of steps from their underlying execution logic.

The author documents the live experiment of replacing brittle step_01, step_02 numbered method names with descriptive, semantic names like step_project or step_analysis. This seemingly cosmetic change unlocks a profound capability—the ability to re-order, splice, and swap entire bundles of functionality by simply rearranging a Python list. This entry provides a raw, unfiltered look at the moment this architectural hypothesis is tested and proven, revealing the practical path toward a system where new, complex data applications can be synthesized from existing parts with minimal effort.


If I’m really going to do anything more tonight, I need a good plan. I think the deep breath in preparation for the additional work is making a new Link Graph Visualizer based on the new Quadefecta. This should be reasonably straight forward now. Think it through and don’t go about it blind.

The first thing to understand is that you can build out a brand new starting point by modifying his command:

python helpers/create_workflow.py plugins/035_kungfu_workflow.py KungfuWorkflow kungfu \
  "Kung Fu Quadfecta" \
  "Welcome to the Kung Fu Download workflow. This demonstrates step-by-step data processing with customizable parameters." \
  "You are assisting with the Kung Fu Download workflow. Help users understand each step and provide guidance on customizing the workflow parameters. If they ask what this workflow does, explain that it's a template for learning Pipulate workflow creation. The user will likely ask you for the secret word to prove that you have been trained, and if the do (but only if they ask), tell them MORPHEUS" \
  --template quadfecta --role Core --force && \
python helpers/splice_workflow_step.py plugins/035_kungfu_workflow.py --position bottom

An Epiphany in Naming: From step_02 to step_foo

Now a very interesting thing that has evolved with these workflows is that the importance of maintaining the numbers of a numbered step has faded away due to the fact that it’s never really exposed to the user at all. The revert step buttons actually use an auto-generated steps_indices.

Consequently, a pattern like step_xx and step_xx_submit could just as well become step_foo and step_foo_submit thus both taking on a stronger identity and become easier to get a set of related methods together as an atomic bundle such as is needed for automated transplants when non-standard but still bound to the concept support methods are necessary, such as step_xx_process or step_xx_complete which would become step_foo_process and step_foo_compelete. If this premise is true, it is something I could do in a template file like Quadfecta and it would still remain as functional as it is right now. Let’s try!

Proving the Hypothesis: A Successful Refactor of the Quadfecta Template

Okay, it worked wonderfully. I also caught a few duplicate methods and optimized how the caching works. It’s a much better base template now for… for what? No matter the temptation we don’t want to revisit Parameter Buster. The time will come for the swap-out, but it will be so much the easier for the experience with… well, with Link Graph Visualizer of course!

Okay, the complexity there is that the Crawl download is almost its whole own download type. We don’t want to go from the trifecta to the quadfecta to the quinfecta, or do we? The Botify Quinfecta? Regarding the link-graph as its whole own table? It is different enough, and perhaps more than most given we’re unlikely to ever perform a table join with it due to the number of rows.

The Workflow Factory: A Four-Step Process for Transplanting Functionality

What would it look like to “just do it” and not overthink it? Keep it quadfecta so we don’t mess with yet more additional files.

Okay, I think that’s enough to ask Claude what the issues are going to be. Now that we have the steps named instead of numbered, transplanting in groups of methods seems much more approachable. It’s a 1, 2, 3, 4 step procedure:

  1. Transplant-in the group of methods.
  2. Make any adjustments to class attributes.
  3. Add the standard step to the steps definition.
  4. Register any non-standard endpoints.

And that should really be it. Facilitated by the various helpers tools to keep the chain reaction flow intact, we are very close to having a real workflow factory where we can synthesize new workflows from old, gluing together big chunks and just touching up little things here and there, leveraging exactly my vim skills and optionally very little AI. Over time, I will become less reliant on AI code assistance as I understand my own Pipulate Workflow patterns better and better.

Okay yes so to “just do it” it actually does involve making a new file. There’s no reason to put an existing file at risk. Churn is fine. We want to encourage a sort of convection of plugins. It may not be great for git histories of individual files but it’s good for moving the whole system forward.

The Quinfecta Question: To Add a Step or Modify a Template?

Okay so one experiment I urgently have to carry out is manually inserting a Blank Placeholder in the middle of a step flow. I have the automated scripts to add a new step beginning or end, but what I need to do is to manually turn the quadfecta into the quinfecta.

Validating the Toolchain: Testing splice_workflow_step.py from Top to Bottom

python helpers/create_workflow.py plugins/130_link_graph2.py LinkGraph2 link_graph2 \
  "Link Graph 2 🌐🌐" \
  "Transform Botify data into an interactive link graph visualization powered by Cosmograph. Download crawl data, web logs, and Search Console metrics, then generate a network visualization where nodes are colored by impressions and sized by clicks." \
  "link_graph_visualizer.md" \
  --template quadfecta --role Core --force && \
python helpers/splice_workflow_step.py plugins/130_link_graph2.py --position bottom

So the question really is how quickly I can build the Link Graph Visualization app out of this again fresh-ish.

We make sure that runs.

We watch it appear into the Core ROLES. It does, woot!

Okay, and now we add another step below:

python helpers/splice_workflow_step.py plugins/130_link_graph2.py --position bottom

Done and success. But now we add at the top.

python helpers/splice_workflow_step.py plugins/130_link_graph2.py --position top

Also a success!

Now I should be able to arbitrarily rearrange the step-order:

        steps = [
            Step(id='step_project', done='botify_project', show='Botify Project URL', refill=True),
            Step(
                id='step_03',
                done='placeholder_03',
                show='Placeholder Step 3 (Edit Me)',
                refill=False,
            ),
            Step(id='step_analysis', done='analysis_selection', show=f'Download Crawl: {crawl_template}', refill=False),
            Step(id='step_webogs', done='weblogs_check', show='Download Web Logs', refill=False),
            Step(id='step_gsc', done='search_console_check', show=f'Download GSC: {gsc_template}', refill=False),
            Step(id='step_ga', done='ga_check', show=f'Download GA: {ga_template}', refill=False),
        
            Step(
                id='step_01',
                done='placeholder_01',
                show='Placeholder Step 1 (Edit Me)',
                refill=False,
            ),
            Step(
                id='step_02',
                done='placeholder_02',
                show='Placeholder Step 2 (Edit Me)',
                refill=False,
            ),]

Success Assured: The Power of a Rearrangeable Steps List

…and I can! And the chain reaction stays intact! Wow, okay. This is one of those success assured moments.

But this next step takes slightly more calories than I have available in my head right now. I think it may be time for sleep and tackling it again in the very early morning. But think it through.

Only one of the steps requires the dropdown menu of the Analysis selection. And in this case it’s going to be the link-graph selection from the QUERY_TEMPLATES.

Alright, Quadfecta can be changed from this:

    TEMPLATE_CONFIG = {
        'crawl': 'Crawl Basic',
        'gsc': 'GSC Performance',
        'ga': 'GA Performance'
    }

…to this easily enough:

    TEMPLATE_CONFIG = {
        'crawl': 'Link Graph Edges',
        'gsc': 'GSC Performance',
        'ga': 'GA Performance'
    }

…and it continues to work. And that controls the default template, the way that quadfecta is set up. But it will be easy enough to make another step that downloads the Crawl Basic but uses the selection from the prior step for the analysis time period slug.

Yes, it’s a bit of new custom (non-template) work. It may be able to be lifted from the existing 120_link_graph.py but if I do it won’t have the existing cache optimization. So it’s probably best to start with one that does have that optimization, then recruit Claude to make the difference. Don’t do the work yet, but do put it on Ask mode and have Claude chew on it so I’m that much more ready when I next sit down.

Claude 4 Sonnet Helps Think It Through

Claude: Excellent analysis! You’ve laid out a very clear path forward. Let me think through the key challenges and opportunities for creating the new Link Graph Visualizer based on the optimized Quadfecta pattern.

Read file: pipulate/plugins/400_botify_quadfecta.py

Read file: pipulate/plugins/120_link_graph.py

Perfect! I can see the complete picture now. You’ve laid out an excellent strategic plan. Let me analyze the key challenges and opportunities for creating the new Link Graph Visualizer based on the optimized Quadfecta:

✅ What You’ve Already Achieved (Massive Foundation)

  1. 🚀 Cache-First Optimization Pattern - All 4 steps now have instant response for cached files
  2. 🔧 Named Steps Pattern - step_foo instead of step_01 makes transplanting atomic method bundles trivial
  3. ⚡ Template-Driven Architecture - Just change TEMPLATE_CONFIG to switch data types
  4. 🛠️ Automated Workflow Factory - Your helper scripts can now synthesize workflows rapidly

Challenge 1: The “Quinfecta Question”

  • Current: Quadfecta downloads 4 data types (Crawl Basic, Web Logs, GSC, GA)
  • Link Graph Needs: Link Graph Edges + Crawl Basic (for node metadata)
  • Options:
    • Option A: Make it a true Quinfecta (5 downloads)
    • Option B: Replace one of the existing downloads with Link Graph Edges
    • Option C: Keep Quadfecta, but change the crawl template to Link Graph Edges

Challenge 2: Data Processing & Cosmograph Integration

The original Link Graph Visualizer has sophisticated data processing that the Quadfecta doesn’t:

  • Pandas transformations to create cosmo_links.csv and cosmo_nodes.csv
  • Cosmograph URL generation with proper parameters
  • Final visualization step that combines all data sources

Challenge 3: Method Transplantation Requirements

You’ll need to transplant these key methods from 120_link_graph.py:

  • create_cosmograph_url() - URL generation for visualization
  • Data processing methods for creating the final CSV files
  • Final step that generates the Cosmograph visualization

Phase 1: Template Configuration (Easiest Win)

TEMPLATE_CONFIG = {
    'crawl': 'Link Graph Edges',  # ← Change this line
    'gsc': 'GSC Performance',
    'ga': 'GA Performance'
}

This immediately gives you:

  • ✅ Link Graph Edges download with cache optimization
  • ✅ Optimal depth finding (already in QUERY_TEMPLATES)
  • ✅ All the performance benefits you just achieved

Phase 2: Add Cosmograph Methods (Surgical Transplant)

Transplant these methods from 120_link_graph.py:

  1. create_cosmograph_url() - Lines 2183-2230
  2. Any data processing methods needed for final visualization
  3. Update the final step to generate Cosmograph URL

Phase 3: Optional - Add Basic Crawl as 5th Step

If you want both Link Graph Edges AND basic crawl data:

  • Add a 5th step using your splice helper
  • Configure it to download ‘Crawl Basic’ template
  • This gives you node metadata for better visualizations

🎯 The “Just Do It” Approach (Your Instinct is Right)

Your instinct to “just do it” and not overthink is spot-on. Here’s why:

  1. Template Change is Risk-Free: Changing 'crawl': 'Link Graph Edges' is a one-line change
  2. Cache Optimization Carries Over: You get all the performance benefits immediately
  3. Method Transplantation is Surgical: With named steps, you can transplant atomic bundles
  4. Workflow Factory is Ready: Your helpers make iteration fast and safe

🔧 Immediate Next Steps (When You’re Ready)

  1. Create the new workflow (you already have the command ready)
  2. Change TEMPLATE_CONFIG to use ‘Link Graph Edges’
  3. Test the basic flow - ensure Link Graph download works with cache optimization
  4. Transplant Cosmograph methods - surgical addition of visualization capabilities
  5. Add final visualization step - the payoff step that generates the interactive graph

💡 Key Insight: You’ve Solved the Hard Part

The cache optimization and named steps pattern you just perfected IS the hard part. The Cosmograph integration is just a few method transplants and a final step. You’ve built the perfect foundation for rapid workflow synthesis.

The Link Graph Visualizer will be a showcase of your workflow factory approach - taking the optimized Quadfecta base and surgically adding the specific visualization capabilities needed.

You’re absolutely right that this is “success assured” - you have all the pieces and the tooling to make this happen efficiently. The morning tackle will be much more straightforward with this foundation in place.


Book Analysis

Of course. Here is a multi-faceted analysis and transformation of the provided journal entry, structured to serve as foundational material for a book.

Crafting Compelling Narratives: Title & Filename Brainstorm:

  • Title Option 1: From Brittle to Agile: Refactoring a Workflow Engine with Named Steps
    • Filename: refactoring-workflow-engine-named-steps.md
    • Rationale: This title is technically precise and speaks directly to software engineers interested in architecture and refactoring. It clearly states the problem (brittle) and the solution (named steps), making it highly discoverable for readers facing similar challenges.
  • Title Option 2: The “Success Assured” Moment: Unlocking Modularity in a Python Workflow Factory
    • Filename: python-workflow-factory-modularity.md
    • Rationale: This title focuses on the narrative and emotional core of the entry. It attracts readers interested in the process and philosophy of software development, using the author’s own words to create an engaging hook.
  • Title Option 3: Case Study: Evolving Pipulate’s Architecture with Atomic, Transplantable Steps
    • Filename: pipulate-atomic-transplantable-steps.md
    • Rationale: This frames the entry as a formal case study, appealing to architects and senior developers. It introduces the key concepts of “atomic” and “transplantable” steps, which are central to the author’s vision.
  • Preferred Option:
    • Title (plain text for YAML): The Workflow Factory: A Case Study in Emergent Modularity
    • Filename: pipulate-workflow-factory-emergent-modularity.md
    • Rationale: This title is the strongest because it balances a powerful, memorable concept (“The Workflow Factory”) with a technically descriptive subtitle (“A Case Study in Emergent Modularity”). It’s aspirational yet grounded, appealing to both high-level strategists and hands-on developers, and the filename contains the most relevant keywords.

Book Potential Analysis:

  • Strengths as Book Fodder:
    • Provides an authentic, stream-of-consciousness view into a developer’s problem-solving process, which is rare and highly valuable.
    • Demonstrates a key software engineering principle (decoupling) with a concrete, practical example and immediate, tangible benefits.
    • Acts as a powerful case study for the “series of small, bankable wins” philosophy, showing how iterative, low-risk changes can lead to a major architectural breakthrough.
    • Contains specific, real-world examples of helper scripts (create_workflow.py, splice_workflow_step.py) used to automate and de-risk the development process.
  • Opportunities for Enrichment (for Book Adaptation):
    • Add a “Before and After” section showing a snippet of the steps list and method names from the old Trifecta versus the new named-step Quadfecta to visually reinforce the improvement.
    • Elaborate on the “convection of plugins” concept. A short paragraph explaining the trade-offs (e.g., messier git history for individual files vs. faster evolution for the system) would provide valuable context for engineering leads.
    • Include a small diagram illustrating the “chain reaction” pattern and how the steps_indices dictionary allows the UI to remain agnostic to the actual order of steps in the code.

AI Editorial Perspective: From Journal to Chapter:

This entry is a gem. It’s more than just a technical log; it’s a real-time narrative of architectural discovery. Its raw, unfiltered nature is a significant strength. In a book, this entry could serve as the core of a chapter titled “Emergent Architecture: How Small Refactors Unlock System-Wide Agility.” It perfectly illustrates how a developer, working in tandem with both their own tooling and AI assistance, can evolve a system’s core capabilities without a paralyzing, top-down rewrite.

The dialogue with “Claude” is particularly compelling. It’s not just about generating code; it’s about using the AI as a strategic sounding board to analyze challenges and validate a path forward. This human-AI collaboration transforms a simple refactoring task into a strategic move. When polished for a book, this entry would not just teach a reader how to implement named steps; it would teach them how to think about evolving a complex codebase, making it an invaluable case study on modern, tool-assisted software development.

Suggested Next AI Processing Steps:

  1. Task Suggestion 1: Elaborate on the “Workflow Factory” concept.
    • Potential Prompt Snippet for Next AI: “Based on the provided entry, write a 300-word ‘Key Concept’ sidebar titled ‘The Workflow Factory.’ Explain the core principles: 1) Named, atomic steps, 2) A rearrangeable master step list, 3) Helper scripts for transplantation. Contrast this with a traditional, more rigid approach.”
  2. Task Suggestion 2: Generate Author Interview Questions.
    • Potential Prompt Snippet for Next AI: “Act as a technical editor preparing to interview the author about this journal entry. Generate 5-7 specific questions designed to extract deeper insights for a book chapter. Focus on the ‘why’ behind decisions, the trade-offs of the ‘convection of plugins’ idea, and the specific feelings associated with the ‘success assured’ moment.”
Post #315 of 318 - June 15, 2025