Are you asking: “Who isn’t messy?” If so, I don’t know anyone who isn’t, but that doesn’t stop people from being judgmental, dismissive, hostile and far too often cruel to others they deem beneath them.
If that’s not the direction you were headed, I didn’t follow your chain of thought and ask that you elaborate so I can attempt to understand.
Sorry that the AI comments derailed the thread. I can say for certain that Jose nor Simon thinks that you are beneath them. You know the saying, “Only a friend will tell you if you have a booger on your nose?” We know you here. You have a strong voice here, and we’d like to hear it. This AI thing is new and we’re all getting used to it. People who used Google Glass were called Glassholes, but now people are wearing Meta Ray Bans and nobody blinks. (And if they do, nobody can’t see it! 
) We’re at the Google Glass period of AI. As Gabe said, once we can add our voice to some of the AI prompts, it will again separate you from the bland, neutral output of every other AI response. We’ll get there. We always do.
I’m ALWAYS interested in conversations related to DevOps and security. You have put some serious thought into the security by shifting early!!! YOU have built something interesting and it has value. Let’s keep this conversation going. You have a lot to offer.
Hello @Kevin_Barrow No insult intended at all, I was empathising 
, I’m the same, and was really being judgemental of myself, if anything. I find I fight that battle on a regular basis, if not daily. Apologies if it was misconstrued.
Epiusers, I 100% agree, should be a place of Psychological Safety at all times.
I want to be clear and explicit—I’ve never felt that anyone here looked down on me, nor have I taken offense to any responses. I tend to communicate transparently and, at times, bluntly, which I realize can be misread.
I apologize for any friction I have caused; it certainly wasn’t intentional. I truly appreciate the feedback and the different perspectives—they only make the framework better, even the side quests have value as they can help reframe the narrative or overcome communication barriers.
Gabe, your point on personalized training is well-taken; it’s the logical next step for my composition workflow. In the meantime, I’ve implemented an architectural mandate (prompt engineering) to bridge that gap immediately.
I call it the Agency-Resolution Protocol. It treats the AI persona as a Non-Newtonian Fluid: it remains fluid for creative tasks but Shear-Thickens into high-density technical rigor the moment it encounters corporate fluff or unrequested prose.
The Agency-Resolution Protocol
This ensures output maintains Technical Momentum over artificial grace. It is already preventing the “Skeleton” of this DevOps framework from being polluted by AI-padding or low-density prose.
I think AI has it’s place in the world but it does give you wrong answer (quite often)…
I’m also waiting for the day it’s all leaked..
Write sloppy code you’ll improve.. like jesus look at my starting out posts.. I basically hounded @hkeric.wci until he would help me.. 
Finishing up with my input… i’ll leave you with boris.. Boris Johnson Says He Loves ChatGPT - YouTube
PS. @josecgomez Way to go starting an anti-ai cult and leaving.. next you’ll have @klincecum telling us how he managed to harness the power of the sun in his pocket watch.. 
I do occasionally watch Styropyro on youtube…
I dislike writing documentation, it’s easier to ask AI to do it, then I only have to iterate until I get the results I desire, either through follow up prompts, or direct edits. AI is good at drafting things, but AI output always needs to be reviewed and fact checked. Although most things you read/write ‘should be’ reviewed and fact checked anyways.
100% - Like I said it has it’s place.
Mark did a fantastic job of providing a comprehensive list of pain points. One that really stuck with me is how much manual effort it takes for admins to keep track of what code exists in each environment. That’s where drift creeps in — eventually nobody is 100% sure what’s actually deployed where, or what should be deployed.
At its core, this isn’t a tooling problem so much as a state‑management problem.
What I’m trying to do is a sanity‑check; I want, ideas, comments, roadblocks and general thoughts:
Does explicitly separating intent, expectation, and reality actually line up with how you want to work? And where would this break down in real‑world Kinetic usage?
This isn’t meant as a prescriptive “do this” solution, but as a way to reason about the problem space.
A single repository with clearly separated responsibilities:
/projects folder — authoritative deployable units/projects — environment‑neutral canonical sourceThe /projects folder is not a convenience directory; it is a governance boundary.
It contains:
Critically, /projects is:
This allows /projects to function as a pure artifact registry, not a working directory.
The master fork (or protected branch) of /projects is the only source from which Training and Production promotions are allowed to occur. No environment may receive anything that does not already exist here.
It defines:
Developers do not deploy “their branch” into higher environments. Pipelines deploy approved artifacts. Promotion is a controlled reference move, not a file copy.
Development environments serve a different purpose than Training or Production: they are integration platforms, not promotion targets.
As such:
/projectsThis enables full CI/CD against a real Kinetic target before changes are merged into main, while keeping main continuously releasable.
Feature branch deployments are explicitly non‑authoritative:
Deployment eligibility is environment‑owned, not pipeline‑hardcoded.
Each environment declares its own deployment policy via secure metadata (e.g., Keyring), such as:
IsProductionAllowedDeploymentSources (FeatureBranch, Main, ReleaseTag)Pipelines evaluate this contract rather than embedding branch logic. This allows:
The environment declares what it will accept; the pipeline merely enforces it.
/projectsmain after Dev validation/projects forkThis model deliberately distinguishes three independent states:
None of these is allowed to overwrite the others silently.
Branches such as env/dev, env/Training, and env/prod do not contain evolving code. They contain references.
They are advanced only by automation, and only after:
They answer a single question:
“What version did we last declare as deployed here?”
They are historical markers, not collaboration surfaces.
Manifests sit orthogonally to branches.
They describe:
They are designed to be violated.
When reality diverges from a manifest, that divergence is surfaced rather than hidden. Drift becomes observable and discussable instead of anecdotal.
The model explicitly supports pulling from environments.
A pull operation:
/projects fork (approved artifacts)Nothing is overwritten. Nothing is “fixed” automatically.
Unexpected changes become evidence, not embarrassment.
The backup fork is not a rollback mechanism.
It is not a workflow tool.
It is forensics.
It answers:
In regulated or audit‑sensitive environments, this alone justifies the model.
/projectsThis does not eliminate complexity.
It names it, constrains it, and makes it survivable.
The framework is now a formal package.
Using uv allows you to run the SDK in an isolated environment without polluting your global Python site-packages:
# Create an isolated venv and install the SDK in one go (once)
uv venv
uv pip install kinetic-devops
#activate the environment (once per session)
./.venv/Scripts/activate
# Run it anywhere
kinetic-devops --help
Note: The kinetic-devops command is now a first-class entry point. No more python -m prefixing.
With the core goal is moving away from “Click-Ops.” I’ve added specific tooling to handle some common migration failures:
kinetic-devops zdatatable: Detects and syncs UD Column drift. It compares ZDataTable XMLs against the target environment to catch field conflicts before the Solution Workbench fails.kinetic-devops solutions: Automates the backup and recreation of Solution Workbench definitions, ensuring .cab and .zip files are reproducible.kinetic-devops meta: Programmatically fetches UI metadata and handles core layer import/delete operations.For those on Windows, bootstrap-dev.ps1 in the repo root automates the full stack:
uv, gh, and VS Code.uv and git best practices.The internal dispatch has been overhauled for better CLI discovery. You can now get deep help on any submodule:
uv run kinetic-devops baq --help
uv run kinetic-devops solutions --help
Next up is hopefully refining the efx and report modules to get us closer to true “Configuration as Code” for Kinetic. Give the uv install a shot—it’s the fastest way to get the SDK live.
I wanted to share a major milestone regarding the framework evolution. I just used v0.1.0a4 to execute a full environment promotion for a Solution containing a Kinetic UI customization and multiple BPMs.
The workflow followed a rigorous verification loop:
The current solutions.py logic successfully handled ZDataTable and ZDataField conflicts automatically. In this case, Dev and Prod shared some legacy custom fields, but Dev had several new columns. The framework resolved these schema differences on the fly, ensuring all new columns were added to the target environment without the manual overhead or the ‘already exists’ errors that usually haunt the standard import process.
Since the 04/02 updates:
Ice.BO.ZDataTableSvc to programmatically reconcile schema differences before the push.The code for this lifecycle is now live in the repo. If you’re tired of the manual friction in Solution Workbench, I’d love for more eyes on the current solutions.py logic—it’s proving to be a huge time-saver for after-hours deployments."