Gregor Woitczyk · Popetto
I want to understand how things work. Their parts, their rules, how they fit together.
From that understanding, I build software, systems and workflows that work reliably and leave time for new ideas.
Software & systems AI & automation Creativity & responsibility
01 / Approach
Yesterday, today, tomorrow and beyond. Four perspectives from my practice: understand, stabilise, transform and automate.
Reliable workflows / Two examples
Making a story playable or running a server: I work out the rules and connections until they form a reliable workflow. Harpin and Ansible show this path from understanding to repeatable execution.
Harpin is my TypeScript interpreter for stories written in Twine’s Harlowe format, created for a narrative game using Phaser. It connects text, choices and game actions while leaving presentation to the game.
Select a point. Motion pauses. Read the step ↓
Beam = project progressThe beam shows project progress, the helix my iterative work around it. Each turn creates a new starting point. Even with clear rules, new findings may call for further rounds. PDCA organises the steps within the four perspectives. About the PDCA cycle ↗
Identify the parts, rules and connections.
For a game, a story is more than a sequence of sentences. It contains passages, links, conditions and instructions. Harpin starts with that structure.
In the project: The parser distinguishes text, links, jumps, variables and other instructions.
A view of the components behind the narrative text.
The parser reads the source file and assigns its elements to passages. A line of dialogue remains text, a link has a destination, and a control instruction gets its own type.
In the project: Dedicated element models represent the different components.
A story whose progression can be examined programmatically.
I need to be able to inspect what a parser has understood. Harpin can export the parsed story as structured JSON, allowing source and result to be compared.
In the project: The example workflow reads a source file and writes the processed structure.
An inspectable translation from text into a data model.
Stories, passages and elements get explicit interfaces. The later execution layer does not have to keep rediscovering the meaning of the original text lines.
In the project: Parser and execution use the same story and element types.
A shared understanding for the next processing steps.
Build a dependable foundation.
A dialogue must not race ahead before it has been read. Harpin makes interruption explicit: selected element types pause progression until the game continues it.
In the project: The element types that trigger interruptions are configurable.
A rule defining when the tool waits.
The interpreter tracks the current passage and next element. An interruption is explicitly resolved before processing continues.
In the project: Passage, element position and interruption state are part of execution control.
A defined place to continue after each pause.
When examining a flow, one step is often more useful than the whole story. Harpin supports processing individual elements and running until the next interruption.
In the project: Single-step and continuous processing are separate execution options.
The progression can be examined at specific points.
The interpreter needs to report what is happening. Harpin provides defined callbacks for events including text, links, interruptions and the end of the story.
In the project: The TypeScript interface describes the events and the data they carry.
An explicit connection between story progression and the game.
Bring things together, reshape them and make them understandable.
The story should be written in its authoring format while the game retains its own presentation. Harpin provides a layer between Harlowe source text and in-game progression.
In the project: The project was developed to bring interactive stories into a custom runtime.
Both tools can retain what they do well.
The parsed story becomes a shared data structure used by the execution layer. The connected application decides how a sentence looks or a choice is presented.
In the project: Parser, data model and processing are separate components.
Narrative and presentation can be changed independently where their interface permits.
A small example story makes the connection tangible. The included example run shows text output, speaker changes and background changes in sequence.
In the project: Example code and its recorded output show the processing of the same story.
A small enough flow to assess how the parts connect.
Not every game action belongs to the narrative format itself. Harpin also recognises custom metadata and passes it to the application, for example for speakers or backgrounds.
In the project: Custom macros and their callback extend the handling of the standard elements.
A shared flow with room for the game’s own requirements.
Hand proven routines over to tools.
Display text in sequence, switch passages, pause and resume: these tasks recur in narrative games. I collect this routine in the interpreter.
In the project: Harpin provides shared processing for different story passages.
The technical flow does not need to be rebuilt for each scene.
The interpreter reads the next element, processes it and invokes the corresponding application callback. The story supplies the sequence; the game supplies the presentation.
In the project: Processing routes text, links and instructions to their respective callbacks.
Repeated wiring becomes a shared tool.
Automatically processed stories still need observable stopping points. The example resolves pauses and lets the flow be followed through to the reported end of the story.
In the project: The example connects interruption, continuation and completion events.
The automated progression remains observable.
Harpin exists as a standalone TypeScript library. Its reusable progression logic is intended to free attention for dialogue, choices and the effect of a scene.
In the project: The package exposes the interpreter and its types for integration.
A tool of my own in service of a creative idea.
Working with AI / Aven
Working with AI produces proposals whose outcome cannot be fully anticipated. I check them, learn from the results and adjust the next step. The goal can stay the same while the path changes.
With Aven, I am developing tools for people and AI agents to work together. Clarifying goals and boundaries, checking results and recording decisions creates a dependable framework for work whose next step can change as we learn.
Select a point. Motion pauses. Read the step ↓
Orbit = project progressThe orbit shows a path whose direction changes. The smaller helix represents my work around it: observe, act, check and adjust. New findings inform the next decision. Returning to the same place in the drawing does not mean starting from scratch. PDCA organises the steps within the four perspectives. About the PDCA cycle ↗
Identify the parts, rules and connections.
Working with AI can reveal a different route to a solution than expected. I first clarify what we want to achieve and how we will recognise a useful result. In Aven, the goal, constraints, workspace and verification belong to the brief.
In the project: The task description also includes risks, expected output and a verification method.
A point of reference that holds when the route to a solution changes.
A tool needs context before it intervenes. Aven CLI exposes the local project state, existing work items and individual tasks through focused queries.
In the project: Overview, listing and detail inspection are separate CLI functions.
Scattered information becomes a workspace that can be examined.
AI generates proposals based on probabilities. Their fit with the task and project state needs to be checked. Aven supports this with checks of work-item structure and documented relationships; assessing the substance remains part of the work.
In the project: Workspace validation and consistency checks produce specific findings.
Open issues remain visible and actionable.
Working with AI should not mean starting from scratch every time. Aven retains local sessions and their history, so a session can be deliberately continued.
In the project: Session history, inspection and continuation are part of the local runtime.
A traceable starting point for the next piece of work.
Build a dependable foundation.
An agent may be capable of running a command without having authority to decide that it should. In Aven, I separate tool capability, permitted scope and responsible approval.
In the project: The runtime treats tool access and permission checks as distinct responsibilities.
A defined scope for local changes.
The local runtime connects tool actions with access rules and change previews. The question of what may be touched becomes part of the workflow itself.
In the project: Local tools, permissions and diffs belong to Aven CLI.
Interventions whose scope can be inspected before approval.
After an action, I check what has actually changed in the project. The findings inform my next decision: continue, revise or adjust the route to a solution. Workspace validation supports this feedback by checking the resulting state.
In the project: The public CLI workflow goes from inspection and change back to validation.
A checked intermediate state from which to decide the next step.
Passing a technical check does not replace acceptance by the responsible person. Aven distinguishes submitting tested work from the decision to accept it.
In the project: Submission and Owner acceptance are separate operations.
Responsibility remains assigned when tools support the work.
Bring things together, reshape them and make them understandable.
Requirements, implementation, verification and decisions are parts of the same work. Aven brings them into a shared project structure rather than managing only isolated agent requests.
In the project: Planning, traceability, validation and delivery decisions are part of the product core.
A connection between the reason for the work, its execution and its verification.
The project structure lives in the workspace itself. Aven CLI can create and inspect work items and carry out supported status transitions.
In the project: The local CLI provides setup, creation and transitions for workspace items.
Process control becomes an operable part of development work.
A shared system still needs clear responsibilities. The CLI handles local tools and files; model access and broader agent automation have their own system boundaries.
In the project: The CLI, Inference Gateway and Aven Backend have explicitly distinct roles.
An architecture whose parts can be developed deliberately.
Penbleth adds a playful representation on top of Aven CLI: a project board and role-playing model make roles, decisions and possible next moves tangible.
In the project: Penbleth is a gamification layer built on the local runtime.
Another way to understand the same work and its connections.
Hand proven routines over to tools.
Checking structures, required information and relationships by hand every time consumes attention. In Aven, these recurring checks become executable operations.
In the project: Validation and consistency checks are commands that can be run repeatedly.
People can focus on what a finding means.
Aven CLI makes project actions explicitly executable. Creating work items, checking their state and submitting work for acceptance become deliberate operations.
In the project: The commands connect local execution with the documented project structure.
Fewer repeated manual steps when maintaining the project structure.
What matters to me is whether a check reveals useful discrepancies. Validation can examine structure; whether a solution is good in its domain remains a broader question.
In the project: Structural validation and responsible acceptance remain separate.
A useful check with a clear scope.
Aven is my work on a framework that handles routine and keeps decisions traceable. The local runtime exists; broader agent automation is part of the system’s continuing development.
In the project: Local CLI functions and backend-supported automation have distinct product scopes.
Room to work on solutions instead of continually maintaining the structure around them.
02 / Work
I am Gregor Woitczyk. I develop software, run systems and invent worlds. I want to understand how things connect – and what that understanding makes possible.
Software · Infrastructure · Operations
I develop applications, interfaces and the infrastructure behind them. With Linux, containers and Ansible, I turn recurring operational work into executable steps with results we can check. Development, testing and operations belong together.
AI · Automation · Process control
With Aven, I am developing tools to coordinate people, AI agents and their work. Aven CLI is the local runtime; Penbleth builds on it. Within ALINA, I also work on connecting and running local AI models.
Explore AvenCIRCUMRADIUS · Medical devices
I am co-founder and technical director of CIRCUMRADIUS, the medical device manufacturer formerly known as Die Hobrechts. My work on RADIUS and experience from several audits connect software development with traceable decisions and processes that have to work in everyday practice.
Games · Rules · Interaction
Game development is part of my work, from Motorsportmanager to Die Wimmelburg HD, which I worked on as a co-founder of Die Hobrechts. With Harpin, I also develop a tool of my own that connects written stories to controllable game progression.
Writing · Worldbuilding · Conlanging
With Gelariad, I am developing an imagined world for stories. Through conlanging, I explore sounds, word formation and writing systems. Rules, history and language need to fit together, even when it all starts with an invented idea.
Recognition
03 / Perspective
I work with dependable intermediate results. Like tested climbing anchors, they support the next move. A cause I understand, a working prototype, a reliable process: each makes it possible to move on and adjust the route as I learn, without unnecessary rework.
I want to build things that work without continually demanding our time. That leaves room for what comes next.
04 / Contact
Tell me what you are working on: a system that keeps needing attention, an unclear process or an idea you want to bring to life.
