The first step was to inspect the actual source, not rely on the handoff notes or the appearance of the page. That exposed a basic problem: the page's JavaScript wasn't executing because of a malformed esc() function.

In other words, the interface could look like a feature existed while the code responsible for making it work was failing. The right response wasn't to polish the screen or declare victory. It was to trace the failure and correct the underlying issue.

The check meant to catch problems had a problem too

There was a second issue. The deployment validator had a broken regular expression of its own, which meant the safety check could fail for the wrong reason.

That matters because a validation step is only useful if the validation step itself behaves as intended. A check that looks reassuring isn't evidence by itself. It needs to be inspected and tested too.

This became a useful debugging rule: don't treat a green-looking process or a completed checklist as proof that the application works. Test the actual behavior, and make sure the checks are trustworthy.

Test the workflow, not just the file

Once the JavaScript issue was fixed, the next step was to exercise the real import flow with a valid JSON sample. That record was imported into the deployed Opportunity Tracker, and the result was confirmed in the actual tool.

I also tried the negative case: a file containing random characters, adfhapdfhu, with a .json extension. It was rejected correctly. The extension doesn't make the contents valid JSON.

That small experiment revealed an opportunity to make the error handling clearer. There are two different situations:

• The file isn't valid JSON at all.

• The file is valid JSON, but doesn't contain a recognizable opportunity record.

Those situations should not produce the same vague response. The importer was improved to distinguish them.

The testing also uncovered a problem that had nothing to do with parsing or JavaScript: the save operation worked, but the confirmation message was visually too quiet. I had to hunt for it.

So the message was made more visible. A user shouldn't have to search the page to find out whether an action succeeded.

The import/export controls also looked disconnected from the section they managed. They were moved next to the imported-files area, where their purpose was easier to understand.

These changes weren't one giant refactor. They were small corrections prompted by using the app as a user rather than judging it from a checklist.

A more useful definition of “done”

This experience changed what I want a completed checkpoint to mean. It shouldn't mean only that a file was edited or that a planned task was checked off. It should mean that the relevant behavior was tried, the result was observed, and the result matched what the feature promised—within the limits of the tests performed.

That doesn't mean every possible path is proven or the entire application is finished forever. It means the claim matches the evidence.

For a small local tool, a practical verification pass can include:

1. Open the real deployed page and try the action a user would take.

2. Exercise a normal valid input.

3. Exercise an invalid or unexpected input.

4. Confirm the visible result, not just the internal operation.

5. Inspect the checks intended to catch regressions.

6. State what passed—and what remains untested—without exaggerating.

The important part is closing the loop between the code, the check, and the user's experience.

The lesson behind the bug

The debugging pattern was simple, even if the route to the fix wasn't:

Claim → inspect the actual thing → find the mismatch → fix it → verify again.

That is also how I'm approaching gitback2life as a whole. I'm disabled and live with complicated health issues; those realities are part of my context, but they're not the entire story. The project is about learning, building useful tools, making sound decisions, and solving practical problems. This particular lesson stands on its own as engineering practice: inspect the thing that exists, not just the thing you expected to exist.

AI can help write code and move through unfamiliar territory faster. It can also help produce a plausible explanation for work that hasn't actually been verified. The solution isn't to avoid AI. It's to use it with a process that includes direct inspection, real testing, and honest limits on the conclusions.

The Opportunity Tracker wasn't really finished when the checklist said it was. It got closer when I tried using the full app, followed the evidence, and fixed what I found.

A feature isn't verified because it looks finished. Try it, observe it, and check the result.

Project: https://gitback2life-art.github.io/gitback2life/

Build notes: https://github.com/gitback2life-art/gitback2life/blob/main/docs/story-log.md

That work became gitback2life.

I didn't start with a giant roadmap or a polished portfolio. I had a computer, curiosity, access to AI tools, and a willingness to learn by doing. The goal was to turn that starting point into real work: code, working tools, practical lessons, and more options for what comes next.

AI helped. It didn't make the hard parts disappear.

AI can explain unfamiliar ideas, suggest code, help investigate errors, and turn a vague idea into something concrete. That is meaningful leverage, especially when you're learning as you go.

But generated code is not the same thing as a verified result. Someone still has to notice when the answer is wrong, decide what matters, try the result, investigate failures, and determine what the evidence actually supports.

That distinction quickly became one of the project's core lessons: AI can accelerate the work, but it doesn't remove the need for judgment.

Start with something real

I wasn't beginning from a blank computer. I already had an AI-assisted Windows task-management application. That meant I could learn from an existing project instead of only writing about the intention to learn programming.

The task manager became a concrete case study. Code changed. Bugs needed investigation. Assumptions had to be checked. And the difference between a feature that appears finished and a feature that behaves correctly for the person using it became impossible to ignore.

That pattern carried into the rest of gitback2life.

The project itself had to be built

Getting a public repository and a GitHub Pages site running wasn't one flawless automated step. There were configuration limits to work around, the wrong settings page to find, a deployment that initially failed, and privacy details that needed attention.

The first visual direction also wasn't right. It felt too bland for the project, so it was replaced with a stronger cyber-tech identity built around a mountain road and sunrise. The point wasn't to make the first attempt look successful. It was to make a better decision after seeing the first attempt.

The working pattern became:

Attempt → problem → investigation → correction → result.

A new tool taught a new lesson

More recently, I built an Opportunity Tracker: a small local tool for recording opportunities, deadlines, source links, evidence, notes, risk, and status.

During testing, I had to ask a basic question: What is this actually for, and where do the opportunities come from?

That exposed a gap in the workflow. The tracker can organize opportunities, but it doesn't create them. The broader process has to include finding, researching, and evaluating legitimate opportunities before saving them in the tool.

Even small tests revealed useful things. I tried to import a file containing random characters—adfhapdfhu—as JSON. The app rejected it, as it should. A file ending in .json isn't automatically valid JSON. That test led to clearer handling for invalid JSON versus valid JSON that doesn't contain a recognizable opportunity record.

Then there was the save confirmation. Saving was working, but the success message was so subtle that I had to hunt for it. I changed the interface because a technically successful action is not enough if the person using the tool can't easily tell what happened.

Those aren't dramatic breakthroughs. They're practical improvements based on using the software and paying attention to what actually happens.

Why document the mistakes?

Because a polished-looking result can hide the work required to get there. I don't want to claim that AI did everything or that every first answer was correct. The useful record includes the wrong turns, the tests, the corrections, and the limits of what has been verified.

That makes the work more useful to me, and potentially to someone else trying to learn how to build with AI in the loop.

The goal of gitback2life is to develop skills, build useful software, and create more choices through practical problem-solving. AI is one tool in that effort; it isn't a substitute for the decisions or verification.

Sometimes the next step is a substantial code change. Sometimes it's figuring out a platform setting. Sometimes it's asking whether a tool solves the right problem. Sometimes it's making a tiny test file full of nonsense to see how an importer responds.

All of that can produce progress when it leads to clearer understanding and a better next step.

This is the beginning, not a victory lap

The public website is live, the repository is available, and the first software projects and lessons are documented. There is still more to learn, more to test, and more to build.

That's the point: not a claim of instant success, but a record of practical work and forward movement.

Building what comes next, one line of code at a time.

Project: https://gitback2life-art.github.io/gitback2life/

Code and project notes: https://github.com/gitback2life-art/gitback2life