The install was the product
KeyControl was a portability problem.
I thought I was cleaning up an old add-on. The evidence pointed somewhere else: KeyControl only made sense when it could leave my memorized WebCentral setup and still install, run, and pass checks for someone else.
KeyControl doesn't run in an empty room. It's a WebCentral product. That means the app, UI, database scripts, overlay files, license path, Tomcat version, Java version, and support checks all have to line up before anyone should trust the install.
The repo made the problem obvious. It had server source, UI source, a WebCentral overlay, SQL Server scripts, a Java SQL runner, validation tools, and shell entrypoints. A folder of old views would have been cleanup. This was an install path that needed to become part of the product.
The workspace made the boundary obvious. WebCentral has to be the primary runtime checkout. KeyControl has to stay its own repo. The deployed UI belongs under the WebCentral app. The source repo doesn't. Mixing those up makes the first QA pass lie.
The question became simple: could a workspace check out WebCentral, check out KeyControl, deploy the product before validation, and leave enough proof for the next person? If not, the product was still living in memory.
A revamp isn't done when the code builds. It's done when someone else can install it, test it, and explain what happened without borrowing your setup.
Two WebCentral lines had to keep working.
"Modernize it" is too vague for this kind of work. One KeyControl line still targets
Tomcat 9, Java 11, and javax.servlet. The newer line targets Tomcat 10,
Java 21, and jakarta.servlet. That package-name change sounds small until
the jar is built against the wrong WebCentral libraries.
So the scripts can't depend on a person memorizing the target. They inspect the
WebCentral root, pick t9 or t10, and still allow an explicit
override when the detection isn't enough. That's the kind of boring behavior old
products need.
The database work had to be rerunnable.
The database told the same story. The current SQL Server path has an install manifest: core, background data, then example data. The notes in the script are blunt about the job. There is no schema history table and no deploy log. Every script has to be safe to run again.
That changes how you write the SQL. Fresh installs need full objects. Upgrade reruns need guarded backfills. Metadata has to come from the target database where possible, not from guesses baked into the script. A small Java runner applies the manifest with the right JDBC driver instead of turning the install into a copy-paste ritual.
Read the WebCentral root and database shape.
Build the server jar against the target libraries.
Sync only the overlay files named in the manifest.
Apply SQL through the runner, not a memorized habit.
Restart Tomcat and wait for WebCentral plus KeyControl.
The package had to carry the install story.
A release package is easy to wave away until someone has to install it without you. Then the contents matter. The package needs the overlay. It needs the UI build. It needs the server jar for the right runtime. It needs database scripts, the SQL runner, a place for JDBC drivers, and the legacy license file path KeyControl still uses.
I don't need to publish license details to make the point. If a package requires a person to remember which jar to pick, which files to copy, where the UI goes, and when to run SQL, the package isn't carrying enough of the product yet.
The support bug was useful evidence.
A failed helper is sometimes better evidence than a clean demo.
Permissions are part of the product.
The workspace issue started with a database reset helper that existed but couldn't read the metadata it needed from the supervisor side. A separate cleanup also made product scripts harder to run from the shared support path because group execute bits were not preserved.
The fix wasn't "give everything more access." The fix was narrower: keep raw credentials private, make generated database metadata readable to the shared group, preserve executable bits, and make the support helper path usable from the supervisor context.
The smoke check mattered because it was plain. WebCentral returned 200. The KeyControl route returned 200. The supervisor-side reset helper could show usage output instead of failing before it started.
If support tools depend on a permission accident, they are not support tools yet.
The workspace had to prove the repo stack.
The CI notes backed this up. KeyControl changes can't be validated as if KeyControl runs alone. The runner has to launch WebCentral first, check out KeyControl as the product repo, deploy KeyControl before validation, and then collect evidence from the combined system.
That run shape catches the failures source review misses. Browser readiness, login, database restore, runtime logs, static checks, Archibot QA, and destination validation all need the same stack shape. Otherwise the review is looking at source while the failure lives in the runtime.
The repo stack preview in Console came from that pain. People should see the runtime repo, product repo, checkout order, branch, path, and deploy-before-validation command. "Two repositories" isn't enough detail when one of them is the room and the other one is the thing being installed into it.
Once those details have names, the work stops being a memory test. A new person can see the package, run the install path, and know what to check before saying it worked.
Old repos remember what the product survived.
This is why old product repos are worth reading carefully. They show what people had to keep alive: database shape, release packages, platform upgrades, license handling, deploy habits, support helpers, and the checks that tell you whether the install worked.
You can't make that portable by putting everything in a zip and hoping the next person guesses right. The portable version says where the source lives. It says what gets copied. It says which runtime was targeted. It says how SQL runs. It says which page checks must pass.
KeyControl didn't need a prettier story. It needed a smaller ritual: write it down, run it, and verify it.