Vibe Check — Devlog

said last devlog i’d be tackling the UI redesign next. did that. also did about four other things i didn’t plan on. classic me.

two days, and somehow: bug fixes, the redesign, AI integration, a whole landing page, and deployment setup. CSS changes enough to make me question my existence 💔

bugs that were silently ruining everything

found out half the buttons in the app weren’t even styled because the css class they used literally didn’t exist 😭

also discovered template search wasn’t searching anything because the input id was missing.

the search bar looked functional.
it was not.
meow.

fixed a bunch of cursed unicode issues too because apparently some checkmarks had transformed into ancient artifacts from another dimension.

the redesign arc 🥀

this one was planned, but it still spiraled way harder than expected.

changed one thing. then another. then suddenly popup.css was over 700 lines.

goodbye neon cyberpunk.
hello warm golds, soft reds, glass panels, crystal backgrounds, rounded corners and way too many blur effects.

the whole thing feels a lot calmer now.
less “rgb gaming keyboard”
more “expensive thing i can’t afford” :3

ai brain upgrade

probably the biggest change, and definitely not planned.

vibe check can now use Cerebras gpt-oss-120b for prompt enhancement.

ended up building support for:

• local development
• chrome extension mode
• production deployment

all using the same enhancement pipeline.

if ai dies the app automatically falls back to local enhancement so users don’t get hit with a giant error message.

because nobody likes giant error messages.

built a whole landing page because apparently i enjoy suffering

didn’t even plan this one.

but now there’s:

• animated hero section
• glassmorphism everywhere
• feature cards
• demo section
• platform showcase
• responsive layout

and enough floating visual effects to make my gpu slightly concerned.

production stuff nobody will notice

added deployment configs.
serverless functions.
environment variables.
request validation.
api key protection.
cors handling.

all the boring stuff that becomes very exciting when it’s missing.

stats

files modified: basically yes
popup.css: 730 lines
popup.js: 1300+ lines

new files:

• landing page
• serverless ai endpoint
• deployment config

:3

Devlog #4 — Heavy Elements Cut, Liquid Hydrogen Locked In

Lead and titanium were off by 50%. I didn’t hide it.

My model tracks how particles slow down inside matter. For heavy elements like lead and titanium, you need a correction for the atom’s electron shells — skip it, and your numbers drift by half the actual value. I haven’t built that correction yet. Faking the results to look clean would gut the whole point of the model. So heavy elements are out for now.

Liquid hydrogen sits at the opposite extreme. One electron, no shell complexity — the model handles it without shortcuts. I checked against NIST’s official proton data: 0.14% deviation across the full energy range. In physics terms, that’s a bullseye.

Five Materials, One Hierarchy

I ran five materials together — liquid hydrogen, methane, polyethylene, water, and aluminum — and tested them as a chain. Two things had to hold: thicker shielding means lower dose, and going from hydrogen to aluminum, dose has to climb, because light elements stop protons better.

Both held, with no exceptions. Polyethylene and water differ by just 3% in electrons per gram — the model caught even that gap correctly.

The sharpest result: at 40 g/cm², liquid hydrogen cuts dose by 44% compared to aluminum. That’s why some spacecraft designs wrap the crew compartment in hydrogen tanks — fuel and radiation shield in one.

All five materials are now locked into regression tests. Total: 103 green tests in CI.

One Function, One Truth

The dashboard and the generated reports used to calculate their numbers separately. Two parallel code paths mean two places for drift to appear. Now both pull from a single shared function. The number on screen and the number in the report are physically incapable of disagreeing.

Devlog #4 — Heavy Elements Cut, Liquid Hydrogen Locked In

Lead and titanium were off by 50%. I didn’t hide it.

My model tracks how particles slow down inside matter. For heavy elements like lead and titanium, you need a correction for the atom’s electron shells — skip it, and your numbers drift by half the actual value. I haven’t built that correction yet. Faking the results to look clean would gut the whole point of the model. So heavy elements are out for now.

Liquid hydrogen sits at the opposite extreme. One electron, no shell complexity — the model handles it without shortcuts. I checked against NIST’s official proton data: 0.14% deviation across the full energy range. In physics terms, that’s a bullseye.

Five Materials, One Hierarchy

I ran five materials together — liquid hydrogen, methane, polyethylene, water, and aluminum — and tested them as a chain. Two things had to hold: thicker shielding means lower dose, and going from hydrogen to aluminum, dose has to climb, because light elements stop protons better.

Both held, with no exceptions. Polyethylene and water differ by just 3% in electrons per gram — the model caught even that gap correctly.

The sharpest result: at 40 g/cm², liquid hydrogen cuts dose by 44% compared to aluminum. That’s why some spacecraft designs wrap the crew compartment in hydrogen tanks — fuel and radiation shield in one.

All five materials are now locked into regression tests. Total: 103 green tests in CI.

One Function, One Truth

The dashboard and the generated reports used to calculate their numbers separately. Two parallel code paths mean two places for drift to appear. Now both pull from a single shared function. The number on screen and the number in the report are physically incapable of disagreeing.

Changing to a real server & a new TACTICAL UI

Added a new Dropdown menu to the TACTICAL page to filter threats by layers and fully changed the backend to the Hack Club Nest server!

The biggest friction this week was dealing with my old Render backend constantly going to sleep, which made the web app feel broken to new users. I finally set up my FastAPI app with PM2 so it stays awake 24/7.

On the frontend, I built a sleek new dropdown to change between Earthquakes, Floods, Storms, and Volcanoes. The hard part was getting the map layers to play nicely together, toggling the new NASA API’s kept overwriting my core 6,000+ wildfire array! I had to rewrite the logic to separate the Leaflet layers so the map can stays fast and doesn’t wipe your data when you switch views.

Right now, I am still trying to fix some bugs and improving the CO2 graph, I am also planning on updating my README.md to explain the new features (better).

THANK YOU FOR READING!
(I am almost at 20 hours of coding omg, I may need to add a special feature for when it happens. Any ideas or improvements are really appreciated!)

Finished the code section!

I finished the code section for my website, finally!

Photography

I rearranged the photos from the “scene” thing into just one continuous thing bcs the scene for me would’ve been too hard for me to design UX and UI around. Also added back scrolling using arrow keys!

Code

Finished everything including projects! This took alot of time and alot of debugging. The code backgrounds are actual text styles with CSS.

EVERYTHING

made the website more responsive!

-ok

Devlog #3 — DOSEFIELD Is Live 🚀Hi! Long time no see.DOSEFIELD is now live: https://izbanovj3-prog.github.io/DOSEFIELD/ The entire dosimeter now runs directly in your browser — no installation required. That includes the controls, dose-vs-thickness chart, particle fragmentation toggle, and validation panel.Under the hood, the project is built with Vite and automatically deployed to GitHub Pages through a GitHub Actions workflow. Every push to the main branch triggers a fresh build and deployment. The setup is intentionally simple: deployment uses GitHub’s built-in Actions token, with no external services and no additional secrets.The only challenge in this release wasn’t physics — it was infrastructure. The first deployment failed because GitHub Actions cannot automatically enable GitHub Pages for a repository. The workflow reached that permission boundary and stopped. After enabling Pages in the repository settings and rerunning the workflow, everything deployed successfully.Once the site was live, I verified that all critical assets were being served correctly. The page, stylesheets, and, most importantly, the Web Worker bundle all return HTTP 200 responses with the correct content types.That Web Worker is particularly important because it handles the species-by-species dose integration calculations off the main UI thread. In practice, this means the interface remains responsive while the physics calculations run in the background.No physics models changed in this release, and the known limitations remain the same. This phase was focused entirely on one goal: shipping a fully accessible browser version of DOSEFIELD.The live demo link is now featured at the top of the README.

Devlog #3 — DOSEFIELD Is Live 🚀Hi! Long time no see.DOSEFIELD is now live: https://izbanovj3-prog.github.io/DOSEFIELD/ The entire dosimeter now runs directly in your browser — no installation required. That includes the controls, dose-vs-thickness chart, particle fragmentation toggle, and validation panel.Under the hood, the project is built with Vite and automatically deployed to GitHub Pages through a GitHub Actions workflow. Every push to the main branch triggers a fresh build and deployment. The setup is intentionally simple: deployment uses GitHub’s built-in Actions token, with no external services and no additional secrets.The only challenge in this release wasn’t physics — it was infrastructure. The first deployment failed because GitHub Actions cannot automatically enable GitHub Pages for a repository. The workflow reached that permission boundary and stopped. After enabling Pages in the repository settings and rerunning the workflow, everything deployed successfully.Once the site was live, I verified that all critical assets were being served correctly. The page, stylesheets, and, most importantly, the Web Worker bundle all return HTTP 200 responses with the correct content types.That Web Worker is particularly important because it handles the species-by-species dose integration calculations off the main UI thread. In practice, this means the interface remains responsive while the physics calculations run in the background.No physics models changed in this release, and the known limitations remain the same. This phase was focused entirely on one goal: shipping a fully accessible browser version of DOSEFIELD.The live demo link is now featured at the top of the README.

Day #1: the hard part is in, now I find out if it’s right

I’m building DOSEFIELD, a 1D model that estimates how much radiation an
astronaut absorbs on a deep-space mission — and how much shielding actually
helps. Cosmic rays in, dose-equivalent out.

What’s already solid: the stopping-power core matches NIST PSTAR reference data
to within 1.6%, and behind 10 g/cm² of aluminium at solar minimum the model
gives 1.96 mSv/day — about 0.70 Sv over a 360-day Mars cruise. That’s 17% past
NASA’s 600 mSv career limit. A round trip to Mars quietly blows through the
radiation an astronaut is allowed for their entire career. That’s the reason
this project exists.

But the first version only tracked primary particles, and it showed: my
aluminium, polyethylene and water curves were sitting almost on top of each
other. That’s physically wrong — polyethylene should shield noticeably better,
because hydrogen is good at breaking up heavy ions. The missing piece is nuclear
fragmentation.

So this week I implemented it — real fragmentation cross sections
(Bradt–Peters), not a fudge factor tuned to match NASA’s measured value. The
material difference has to come out of the physics: hydrogen has the shortest
nuclear interaction length per g/cm², so it should win on its own. No parameter
is fit to the answer.

Now I’m validating it, and I’m writing the test down BEFORE the result so I
can’t quietly move the goalposts. If the physics is right, I should see four
things: the curves separate (polyethylene below aluminium), aluminium flatten
out at depth, the mean quality factor drop from 4.82 toward ~3.5–4, and the dose
move closer to the real MSL/RAD cruise measurement. If they don’t, the model is
wrong and I’ll say so.

Numbers in the next entry. Either it works or it doesn’t — that’s the whole
point of logging the test first.

What it still isn’t: 1D, simplified fragmentation, not a replacement for NASA’s
HZETRN. Every value traces to a cited source, and the validation suite re-runs
on every change.

DOSEFIELD DAY #2:Fragmentation is now in the live app. Until today the web dosimeter only ran the primary-only transport — the most interesting result, that breaking up heavy ions is why hydrogen-rich shielding wins, was buried in a console script. Now there’s a “Primaries only ⇄ + Fragmentation” toggle, and flipping it visibly bends the curves: polyethylene pulls away from aluminium and the mean quality factor drops. Concretely, at solar minimum behind 20 g/cm², polyethylene’s edge over aluminium jumps from 12% to 34% the moment fragmentation turns on — the same figure the validation script prints, read from the same function, not hardcoded. Mean ⟨Q⟩ behind 16 g/cm² of aluminium falls 4.47 → 4.14. Nothing was tuned; the toggle just calls the existing Bradt–Peters model. And the honest ceiling stays put: still no secondary neutrons, so the absorbed-dose gap vs the real MSL/RAD measurement (~0.31 vs 0.46 mGy/day) remains — and the UI footnote says so out loud. 76/76 tests green, build clean. Next: surface the NIST + RAD validation inside the app itself. 

When I first registered for NASA Stardance, Aetheris was already well into development—about 60-70% complete. That’s why my very first official devlog kicked off at Day #6 instead of Day #1. At the time, I just wanted to focus on shipping, but looking back, I want to be transparent about the whole journey.**Even though this devlog covers the timeline from Day 1 to Day 6, the project itself has actually been in the works since March. The idea originally sparked back then under the name “ecomap.” Back then, it only covered air quality districts in Almaty rather than the entire country of Kazakhstan. **However, after that initial phase, it sat on the back burner for a bit. It wasn’t until June that I finally committed to it 100% and went all in.//////////////////////////////////////////////////// Day 1 — FoundationSet up the Next.js 16 project with the App Router and configured it for a fully static build (every route prerendered, no server runtime). Laid the geographic base: Natural Earth land polygons that drive the particle globe. Built the first shell of the landing page./////Day 2 — Map layer systemStarted the map’s layer system. Designed and built the layer legend, which locked in the five environmental layers the whole app is built around: air, industrial, water, biodiversity, and risk./////////Day 3 — Data engine & first surfacesThe biggest push. Built the deterministic simulation engine — a full environmental profile (AQI, PM2.5/PM10, NO₂, temperature, water quality, biodiversity, emissions, sustainability score, 90-day trends) for 28 cities, one per region of Kazakhstan. All values are seeded, so every screen reports the same numbers. On top of that, built the cinematic landing page with a Three.js particle globe and the analytics dashboard with custom SVG charts (temperature anomaly, AQI trends, city rankings). Also scaffolded the map and AI assistant routes and self-hosted the map label fonts so there’s no external CDN dependency — ready to be wired up next.///////////Day 4 — TestingReviewed and tested the build end to end, checked all routes render correctly in the static export, and validated the data across surfaces.////////////Day 5 — Polish & deployFinalized the navigation and the design system (color palette, typography, motion, glass/scanline textures). Centralized all site metadata, SEO, and PWA config into a single source. Fixed a URL-parsing edge case, ran the static production build, and deployed.///////It’s been a wild ride, and I am incredibly happy to say that I have finally finished it!

Day 6 Update: Live AQI Map & AI Analyst for Aetheris 🌍🇰🇿

Today I spent my session building out the core infrastructure for Aetheris. My main goal was to bring the Kazakhstan Atlas to life and connect it with our AI reasoning engine.

What I built today:

• Set up live data fetching for AQI and PM2.5 across 28 cities in Kazakhstan.
• Implemented the logic for the Environmental AI layer. The assistant now processes real-time sensor data and explains the context (e.g., the heavy smog caused by winter temperature inversions in Almaty).

Challenges faced:
Processing such a massive volume of environmental data points caused severe UI lag during the initial map render. I resolved this by optimizing the data arrays and implementing server-side caching.

Next steps:
In the next session, I will focus on the Community system so citizen scientists can start logging local pollution events and earning contribution points.

DOSEFIELD DAY #2:Fragmentation is now in the live app. Until today the web dosimeter only ran the primary-only transport — the most interesting result, that breaking up heavy ions is why hydrogen-rich shielding wins, was buried in a console script. Now there’s a “Primaries only ⇄ + Fragmentation” toggle, and flipping it visibly bends the curves: polyethylene pulls away from aluminium and the mean quality factor drops. Concretely, at solar minimum behind 20 g/cm², polyethylene’s edge over aluminium jumps from 12% to 34% the moment fragmentation turns on — the same figure the validation script prints, read from the same function, not hardcoded. Mean ⟨Q⟩ behind 16 g/cm² of aluminium falls 4.47 → 4.14. Nothing was tuned; the toggle just calls the existing Bradt–Peters model. And the honest ceiling stays put: still no secondary neutrons, so the absorbed-dose gap vs the real MSL/RAD measurement (~0.31 vs 0.46 mGy/day) remains — and the UI footnote says so out loud. 76/76 tests green, build clean. Next: surface the NIST + RAD validation inside the app itself. 

Day #1: the hard part is in, now I find out if it’s right

I’m building DOSEFIELD, a 1D model that estimates how much radiation an
astronaut absorbs on a deep-space mission — and how much shielding actually
helps. Cosmic rays in, dose-equivalent out.

What’s already solid: the stopping-power core matches NIST PSTAR reference data
to within 1.6%, and behind 10 g/cm² of aluminium at solar minimum the model
gives 1.96 mSv/day — about 0.70 Sv over a 360-day Mars cruise. That’s 17% past
NASA’s 600 mSv career limit. A round trip to Mars quietly blows through the
radiation an astronaut is allowed for their entire career. That’s the reason
this project exists.

But the first version only tracked primary particles, and it showed: my
aluminium, polyethylene and water curves were sitting almost on top of each
other. That’s physically wrong — polyethylene should shield noticeably better,
because hydrogen is good at breaking up heavy ions. The missing piece is nuclear
fragmentation.

So this week I implemented it — real fragmentation cross sections
(Bradt–Peters), not a fudge factor tuned to match NASA’s measured value. The
material difference has to come out of the physics: hydrogen has the shortest
nuclear interaction length per g/cm², so it should win on its own. No parameter
is fit to the answer.

Now I’m validating it, and I’m writing the test down BEFORE the result so I
can’t quietly move the goalposts. If the physics is right, I should see four
things: the curves separate (polyethylene below aluminium), aluminium flatten
out at depth, the mean quality factor drop from 4.82 toward ~3.5–4, and the dose
move closer to the real MSL/RAD cruise measurement. If they don’t, the model is
wrong and I’ll say so.

Numbers in the next entry. Either it works or it doesn’t — that’s the whole
point of logging the test first.

What it still isn’t: 1D, simplified fragmentation, not a replacement for NASA’s
HZETRN. Every value traces to a cited source, and the validation suite re-runs
on every change.

Day 6 Update: Live AQI Map & AI Analyst for Aetheris 🌍🇰🇿

Today I spent my session building out the core infrastructure for Aetheris. My main goal was to bring the Kazakhstan Atlas to life and connect it with our AI reasoning engine.

What I built today:

• Set up live data fetching for AQI and PM2.5 across 28 cities in Kazakhstan.
• Implemented the logic for the Environmental AI layer. The assistant now processes real-time sensor data and explains the context (e.g., the heavy smog caused by winter temperature inversions in Almaty).

Challenges faced:
Processing such a massive volume of environmental data points caused severe UI lag during the initial map render. I resolved this by optimizing the data arrays and implementing server-side caching.

Next steps:
In the next session, I will focus on the Community system so citizen scientists can start logging local pollution events and earning contribution points.