Project page: AssetTrack
AssetTrack is built around one simple rule:
The event log is the truth.
That means every workflow change has to be careful. A cleaner button, a better email action, or a smoother validation screen cannot quietly change custody truth, receipt truth, audit history, or persistence behavior.
Today’s work stayed focused on that discipline.
The recent receipt email work had already made the admin resend path safer and cleaner. From there, the next question was not “what can we build next?” It was “what do we need to close, document, and understand before the next behavior change?”
That is slower in the short term, but safer for the system.
We worked through several Issue 27 cleanup and recon items.
First, we confirmed that the holder follow-up email action was already implemented on main by earlier work. No new code was needed. The existing behavior already supports a manual holder follow-up email from the holder detail page, using the local SMTP configuration, without writing to the database or changing custody or receipt truth.
That issue was closed as already satisfied.
Next, we added a pre-event validation checklist.
That checklist documents what AssetTrack must confirm before any event-producing workflow appends custody history. It covers authentication, authorization, workflow intent, required context, asset eligibility, queue validity, preview confirmation, append-only commit boundaries, SQLite persistence expectations, post-commit reconciliation, and receipt/email separation.
The point is simple:
Validation happens before the event is appended.
Once the event is appended, history is not edited to make the workflow feel cleaner later.
Then we completed recon on multi-location holder support.
The finding was important. Holders are currently global custody actors, not location-scoped records. A holder can operate across approved locations without needing a schema change. Issue location is transaction context. Receipts snapshot holder identity and location separately. That means no runtime change is needed right now for a holder working across multiple locations.
The recon also identified two possible future paths, but only if operators need them later:
Finally, we completed recon on validation flow and redundancy.
The current Issue and Return workflows still preserve the correct seam:
entry page → prerequisite selection → scan queue → preview → commit
That seam matters because preview is the operator’s main checkpoint before custody events are appended. Commit handlers and transaction helpers also revalidate state before writing events. That duplication is intentional. It protects custody truth.
The recon found a few presentation-only simplification candidates, including repeated guidance and blocked-state summaries, but it also clearly marked the checks that must not be removed.
A system like AssetTrack does not get safer just because it has more code.
It gets safer when the rules are written down, checked, and respected.
The pre-event checklist gives future issues a shared reference point. Instead of re-arguing every workflow decision from scratch, we now have a plain checklist that says what must be true before AssetTrack writes an event.
The multi-location holder recon also helped prevent premature schema work. It would be easy to assume holders need location membership records. But the current model already supports the real operational case: a global custody actor participating in transactions at different locations.
That matters because schema changes are expensive. In AssetTrack, they are not just database changes. They affect event interpretation, receipts, custody reports, workflows, and operator trust.
The validation recon reinforced another lesson:
Some repetition is bad interface design. Some repetition is system protection.
The job is knowing which is which.
Repeated helper text may be simplified later. Commit-time validation should stay.
The next useful work should stay small and disciplined.
Good candidates include:
Before any behavior-changing issue, the new pre-event validation checklist should be used as a guardrail.
The goal remains the same:
Keep AssetTrack simple for the operator without making the custody model weaker behind the scenes.
]]>Project page: AssetTrack.
This phase of AssetTrack was not about adding features.
It was about reducing friction.
Over time, the system had accumulated:
Nothing was technically broken.
But the system was becoming mentally noisy.
That matters in a field-oriented operational application.
Operators should not feel like they are navigating a SaaS dashboard.
They should feel like they are operating a focused tool.
Several connected UI refinement issues landed during this phase.
Highlights included:
One interesting correction happened late in the cycle.
During consistency cleanup, the UI standardized on:
Stage Assets
But smoke testing showed that operators naturally responded better to:
Add Assets
That small wording difference mattered more than expected.
“Stage” reflected the internal workflow architecture.
“Add Assets” reflected the operator’s actual mental model.
The system now consistently uses:
Add Assets
→ Preview Queue
→ Commit
which reads much more naturally during operation.
There is a major difference between:
functional UI
and:
operational cognition
A system can technically work while still exhausting the operator.
As AssetTrack matured, the problems stopped being backend problems.
The problems became:
The most surprising lesson was that reducing noise exposed deeper cohesion problems.
Once the clutter disappeared, inconsistency became visible immediately.
That was actually a good sign.
It meant the system was finally calm enough for polish problems to surface.
Next work will likely focus on:
The goal is increasingly clear:
AssetTrack should feel less like a web application and more like a dedicated operational appliance.
]]>Project page: AssetTrack.
AssetTrack is at the stage where the major workflows exist, but the operator experience is starting to matter more than raw feature count.
The system already works.
Now the question becomes:
Does the system feel understandable under pressure?
That led into a chain of navigation and presentation cleanup issues focused on reducing cognitive load for operators.
The biggest realization today was that navigation has layers:
global navigation
local workflow navigation
workflow actions
When those layers visually compete, the operator has to stop and think.
That is exactly what we do not want in a field inventory system.
Completed UX/navigation cleanup chain:
/add-assets action hierarchyThe most interesting fix today was probably not visual at all.
The theme toggle had a subtle accessibility mismatch where the server-rendered HTML did not initially include the correct aria-pressed state. JavaScript eventually corrected it, but there was a brief mismatch between what the page showed and what accessibility tools understood.
The fix itself was tiny:
one missing attribute
But those are the kinds of details that quietly erode trust over time if left unresolved.
I also simplified the dark mode toggle into a compact icon-only control. Removing words from the navbar sounds small, but it noticeably reduced visual noise.
I discovered an important distinction today:
actual layout inconsistency
vs
perceived layout density
Originally I thought several admin pages had width problems.
After recon and testing, the real issue was only one outlier route using a narrower container.
Everything else that still felt different came from:
That matters because it prevents over-fixing the wrong problem.
Another lesson:
tiny UI inconsistencies compound
One slightly different nav row. One awkward button hierarchy. One oversized text label.
Individually they seem harmless.
Together they create friction.
Next up is likely continued workflow cognition cleanup:
The system is starting to feel calmer.
That is the goal.
]]>Project page: Settled Field Platform.
Today was about getting the site out of the local/dev lane and into the real world.
The goal was not perfection.
The goal was:
Make the site credible, clean, and available before Bill’s meeting.
That meant focusing on flow, trust, and deployment instead of adding more features.
Settled on the Field is now available here:
The domain is managed through Bluehost, while the app is deployed through Vercel.
The key production setup became:
Bluehost DNS → Vercel → Settled Field Platform
The site now has:
This moved the project from:
pages in progress
to:
a usable public experience
The CurlTech attribution went through a few iterations.
The final version uses:
This kept the credit present without letting it compete with the site.
The code was not the hard part today.
The tricky part was DNS:
www needed the correct CNAMEThe lesson:
If the site works but Vercel says invalid, check for duplicate or conflicting DNS records.
Once a site is public, placeholders feel different.
Every fake email, broken link, or loud attribution suddenly matters more.
That pressure was useful.
It forced the site to become more honest.
The footer logo issue looked like a CSS problem at first.
It was really an asset problem.
The PNG had sizing/canvas issues, so the fix was to use a proper SVG and size it with em.
Lesson:
Fix the asset layer before fighting CSS too hard.
This version is not the final product.
But it is good enough for a real conversation.
That matters.
A live, credible site creates momentum in a way a local build never can.
After Bill’s meeting, the next work should focus on:
Today the project crossed a line.
It is no longer just a build.
It is now a live system with a real address:
That changes the conversation.
]]>Project page: Settled Field Platform.
I’m working toward a meeting-ready version of the Settled Field Platform site.
The goal isn’t perfection.
It’s credibility.
If someone lands on the page, they should:
Before today, the site had structure, but it still felt like a template.
Clean… but not convincing.
I shifted the landing section into more of a “poster” feel:
It started to feel like an event instead of a webpage.
I introduced:
Then centralized everything in globals.css.
This wasn’t just about fonts.
It made the hierarchy obvious and removed visual noise.
Big realization here:
The buttons looked styled, but they didn’t feel clickable.
The issue wasn’t color — it was separation.
Fix:
Now the CTA sits above the hero instead of blending into it.
This was the biggest shift.
Right after the hero, I added a section that answers:
No fluff. No long paragraphs.
Then on the summit page:
The site now answers:
“Why should I care?” within 10 seconds
You can have:
…and still not convert.
Trust comes from:
I tried glow. Didn’t like it.
The real fix was:
make the button feel like it exists on a different layer
Simple shadow + solid fill beat everything else.
Adding a trust section exposed overlap with existing sections.
Lesson:
every section has to earn its space
If two sections say the same thing, one has to go or tighten.
At one point I assumed fonts weren’t applying because of Next.js font output.
Reality:
computed styles told the truth
The pieces are all there now:
Next step is tightening flow:
what the user sees first → second → where they click
That’s where this becomes a real conversion system.
Today wasn’t about building more.
It was about removing doubt.
That’s the difference between:
Project page: AssetTrack.
After deployment and email delivery were stabilized, the next gap became clear:
Authentication recovery.
In a real system, users will forget passwords.
If recovery is weak, the system is fragile.
If recovery is too powerful, the system becomes unsafe.
This work focused on building a reset path that:
At the same time, the system accumulated test data and UX friction that needed to be cleaned up before moving forward.
This was both a security pass and a reset to a clean operational state.
A reset flow was introduced with these properties:
The key constraint:
no schema change allowed
Instead of adding a column, a marker prefix was applied to the existing password hash:
assettrack-temp-password:<hash>
This allowed the system to:
This kept the system stable while extending behavior.
Initial implementation failed at login.
Symptom:
Root cause:
Fix:
This was a small change, but important.
It reinforced a rule:
Any encoding or wrapping of stored values must be understood everywhere that value is read.
After successful login with a temporary password:
This ensures:
Temporary passwords are:
Hardening added:
Cache-Control: no-storePragma: no-cacheExpires: 0This reduces risk of:
Delivery to the user is intentionally out-of-band:
The system does not attempt to deliver secrets.
Reset does not modify account status.
If a user is:
This avoids:
The system separates:
This is intentional.
At this point, test users and data were polluting the system.
Instead of partial cleanup:
Result:
Bootstrap was then used to:
This restored the system to a true baseline.
Inventory import was run manually after reset.
It is not part of startup.
This is by design.
If import ran automatically:
Import is treated as a controlled data operation, not a system requirement.
One small issue had outsized impact:
Buttons did not show a pointer cursor.
Effect:
Fix:
button { cursor: pointer; }
This did not change behavior.
It changed perception of reliability.
The reset flow could have introduced new columns.
It didn’t.
By reusing existing structure carefully, the system gained capability without increasing migration risk.
The system worked — except for one detail:
A prefix.
That small mismatch broke the entire flow.
Lesson:
Every transformation of stored data must be reversible at every read point.
Password reset did not:
That separation keeps the system predictable.
Deleting test users manually risks:
Resetting the database created:
The pointer cursor fix did not change logic.
But it changed:
That matters in a field system.
Issue 26-152 — Improve Admin User Reset Flow Clarity
The system works correctly, but the UI still requires operator thinking:
Next step:
The system is now:
The biggest changes were not structural.
They were about:
That is what turns working code into a reliable system.
]]>Project page: Settled Field Platform
Up until now, this build was moving toward something real, but not fully operational.
We had:
But we didn’t yet have:
That’s what Milestone 3 was about.
And today, that layer is done.
This milestone introduced the full admin control layer.
owneradminThis is no longer “fake login.”
It’s real auth.
We now have the complete flow:
/admin/request-access)/admin/requests)With guardrails:
This is a controlled system, not a free-for-all.
Getting this live surfaced something important:
A working system locally is not the same as a working system in production.
To make admin login work on Vercel, three things had to be true:
DATABASE_URLADMIN_SESSION_SECRET presentThat last one was the trap.
Without it:
UnauthorizedOnce that was fixed, everything snapped into place.
I created the first production owner via CLI, then logged in through the live app.
That’s the moment this stopped being:
“a thing I’m building”
and became:
“a system that can be operated”
Then I brought in a second user as admin.
No CLI. No database work. No dev intervention.
Just:
That’s the shift.
You need:
Miss one → system fails in non-obvious ways
You can’t fake:
Those seams will break if they’re not real.
Pages don’t make a product.
Control does.
Now the system can:
That’s the difference between:
demo
and
product
Milestone 4:
Payment Hardening (Stripe)
Up next:
That’s where this becomes:
not just usable
but valuable
This was a big one.
The system is now:
Next step: make it real revenue.
]]>Project page: Settled Field Platform.
Up to this point, the project was a strong front-end funnel:
Landing → Summit → Register → Success → Checkout (stub)
It looked real. It behaved well. But it was missing something critical:
Operational control.
There was no way for Bill (or anyone helping him) to actually see or manage what was happening inside the system.
That changed today.
Milestone 3 is now complete.
That includes:
The key shift:
The system moved from collecting data to owning data.
Registrations are no longer ephemeral—they are stored, structured, and visible.
Admins are no longer theoretical—they can log in and operate.
The biggest lesson here wasn’t technical—it was architectural discipline.
I initially tried to build the attendee list first.
That failed for the right reason: the system didn’t actually store attendees yet.
So I had to step back and build the persistence layer first.
That decision:
Another key takeaway:
Authentication doesn’t need to be complex to be correct.
Instead of introducing a full auth system, I implemented:
Simple, controlled, and appropriate for the use case.
Next is Milestone 4: Payment Hardening.
That includes:
Right now: we can see who registered.
Next: we need to know who committed.
This is the milestone where the project stopped being a site and became a system.
Before:
Now:
That is the difference between something that looks complete and something that can actually run an event.
]]>Project page: gregcurl.dev Rebuild
I’m rebuilding my portfolio into a working consulting platform.
The goal isn’t a better-looking website — it’s a system that:
Before writing any application code, I focused on getting the foundation right.
Milestone 0 is now complete:
gacurl-web).env.example)This means the project now has a stable, security-conscious starting point.
The biggest lesson is that discipline early prevents rework later.
It’s tempting to jump straight into building pages, but that usually leads to:
By locking these decisions first, the rest of the build becomes much more straightforward.
Milestone 1: Scaffold the Next.js application.
This will:
From here, the project shifts from planning → execution.
]]>Project page: Settled Field Platform.
Up until now, everything looked good — but it wasn’t real yet.
Milestone 1 gave me:
But it was still a surface.
Today was about turning that surface into behavior:
Without overbuilding the backend.
Two major things happened.
The form now:
That last part matters.
Instead of jumping straight into a database, I used a draft model:
This keeps the system light while still making it real.
Stripe isn’t live yet — and that’s intentional.
What is live:
Flow now looks like:
Register → Payment-ready → Checkout seam → Stub (for now)
No fake success.
No dead ends.
No pretending.
Just forward motion.
It’s tempting to jump straight into:
But that would’ve slowed everything down.
Instead:
Each step supports the next, without locking anything in.
The biggest improvement today wasn’t technical.
It was removing the “app UI” feel from /register.
Once I aligned it with the same:
…it stopped feeling like a form and started feeling like a step in a journey.
That’s the difference between:
Every step now answers:
“What happens next?”
Even without Stripe live, the system moves.
Two paths, depending on timing:
Today was the shift.
This isn’t a website anymore.
It’s a system.
]]>