DEV Community: Katsuo Imai

Building PROTO RECON — From Vague Idea to a Browser-Based Tactical HUD

Katsuo Imai — Sun, 24 May 2026 00:12:32 +0000

Introduction

This post walks through how PROTO RECON — an experimental app that combines phone sensors with in-browser ML — evolved from pre-coding requirements to its current implementation. I've verified the UI behavior, but I'm still at the stage of reading the source code for the first time. Here I organize the original requirements and an AI-generated source map as a foundation for deeper dives in future posts.

Live demo (experimental): Proto Recon (Cloudflare Workers)
Repository: github.com/katsutoshi0katsutoshi/proto_recon
Sandbox for isolated experiments: CodePen / @wlzpaovm-the-bashful

Note: This is still in testing. Performance tuning for heavy workloads hasn't been done yet — use at your own risk.

Where It Started

It began with a vague question: Can we build a digital user experience on top of the real world? The seed of the idea was whether today's phone sensors could overlay something like the robot-view or cockpit-view perspectives from old sci-fi and games onto live scenery.

Before writing code, I summarized the requirements, turned functional specs into prose through dialogue with AI, and then started development.

Technology Choices (Before Implementation)

Area	Adopted / Considered	Notes
Object detection	TensorFlow.js (COCO-SSD / BlazeFace)	"Object recognition" as the core of the robot-view feel, fully in the browser
Map	Leaflet	Familiar "you are here" display from games
Noise / effects	Initially GLSL / three.js	Wanted to reuse past effect-building experience

The noise layer was added later. When I had Cursor implement it, three.js was skipped in favor of Canvas 2D and CSS for CRT-style effects. Writing directly without extra modules kept things lighter — a decision that has paid off on real devices.

Gyro, compass, altitude (on supported devices), GPS, and similar sensors were also in scope, wired to the HUD and minimap.

Requirements at the Time (Summary)

The planning document — built through repeated conversations with AI — was titled Tactical Recon & Guidance Terminal "PROJECT: LOCK-ON (working title)". At that point, sensor accuracy led us to assume Phase 2 would require a Unity (native) rewrite. After coding with Cursor, however, things moved better than expected even without three.js, and the outlook shifted to Phase 1 might be achievable on the web alone.

Core Concept

Visuals: Monochrome green military-terminal UI, scan lines, noise
AI: Real-time object detection for targeting and lock-on
Immersion: Gyro, altitude, BEEP sounds — instrument and audio feedback
Future: VR-goggle HUD, gaze control (concept stage)

Plan vs. Current State

Item	Plan (as of Apr 2026)	Current (PROTO RECON)
Stack	Next.js + Three.js + TF.js	Vite + vanilla JS + TF.js (no Three.js)
Altimeter	Barometric sensor (native assumed)	Geolocation `altitude` (supported devices only)
Map	(lightly specified in the plan)	Leaflet minimap implemented
Missile effect	Tap to fire a virtual missile	Not implemented
Phase 2 Unity	Barometric altitude, haptics, etc.	Not started (web prototype continues)
Distance display	(mostly undefined in planning)	WebXR hit-test measurements only (no bbox-estimated distance)

The full planning document is collapsed below due to length.

Full planning document (PROJECT: LOCK-ON draft)

Tactical Recon & Guidance Terminal App — "PROJECT: LOCK-ON (working title)" Planning Document

This document summarizes a concept for a smartphone camera-filter app that blends retro-futuristic UI with modern AI.

1. Project Overview

A "play" app that recreates the experience of a military recon terminal from 1980s–90s sci-fi films and games, using live smartphone camera feed and AI.

2. Core Concept

Visuals: Monochrome green evoking old terminals. Retro feel via scan lines and noise.
AI interaction: Automatic targeting and lock-on through real-time object detection.
Immersion: Gyro, barometric sensor (altimeter), BEEP feedback.
Extensibility: HUD and gaze control with VR goggles (e.g. Hacosco) — concept stage.

3. Main Features (excerpt)

3.1 Video filter

Green overlay (night-vision goggle texture)
Edge bar graphs and scan indicators

3.2 AI lock-on

Automatic moving-object detection with green bounding-box tracking
SE accelerates when the target stays in the reticle center
Lock complete: box turns red, warning sound
Tap to fire a virtual missile (effect)

3.3 Sensor-linked instruments

Gyro: pitch and roll numeric display
Altimeter: relative altitude from barometric sensor (iPhone, etc.)

4. Development Phases (roadmap at the time)

Phase 1: Web prototype (Next.js + Three.js + TF.js). Shareable via URL.
Phase 2: Unity port. Barometric altitude, vibration.
Phase 3: VR/XR. Stereoscopic display, gaze lock-on.

5. Distribution Strategy

Dev logs on Qiita / Zenn, short-form video on social, posts on Reddit, etc.

Created: April 29, 2026 (planning stage)

How Development Proceeded

Coding was delegated to Cursor, adding features one prompt at a time until the current state. For prompts, I load the requirements document into Gemini and ask what kind of prompt would work best. I've checked JS behavior through the UI, but reading the source comes next. The file list and dependency diagram below were AI-generated and cleaned up for this article.

Source Layout

HTML (root level)

File	Role
`index.html`	Main screen. BIOS/splash, boot progress, camera feed, reticle/detection overlay, compass/altitude tape, minimap, CRT effects, etc. Loads `/src/main.js` as a module
`privacy.html`	Privacy policy (static page: collected data, purpose of use, etc.)
`oss-notice.html`	Static OSS / third-party license notice

`src/` — runtime files

Entry, config, UI

File	Role
`main.js`	App hub. Boot sequence, camera acquisition, start/stop of modules, HUD updates, user actions (start/stop, lock, .etc.)
`appConfig.js`	Dev tuning defaults (camera, CRT, object detection, face mask, minimap, motion linkage, live health, etc.)
`applyDevConfig.js`	Applies `devConfig.crt` as CSS variables on `document.documentElement` (vignette, scan lines, etc.)
`uiLexicon.js`	Single source for UI copy (splash, status, errors, minimap labels, etc.) including functions to apply text to HTML
`style.css`	Global layout, HUD, CRT, minimap, reticle styles (green military UI)

Video & AI inference

File	Role
`tfBackend.js`	One-time TensorFlow.js backend init (WebGPU → WebGL → CPU)
`personDetection.js`	COCO-SSD object detection. Bounding-box drawing, lock zone, target events, inference health notifications
`facePrivacy.js`	BlazeFace face detection and masking (privacy overlay)
`lockTrackKeys.js`	Stable IDs for targets in the lock zone (position quantization + match with previous frame)

Distance & AR

File	Role
`objectRange.js`	Distance to target on HUD — measured distances only (WebXR, etc.); no bbox-estimated distance
`webxrHitTestRange.js`	WebXR immersive-ar + hit-test for real-world distance (m) fed into `objectRange`

Navigation, map, sensors

File	Role
`compass.js`	Device heading (compass) wrapper. Heading parse, cardinal labels, iOS permission request
`miniMap.js`	Geolocation watch and minimap facade (position, heading, speed, altitude callbacks)
`miniMapLeaflet.js`	Leaflet map init, current-location marker (heading arrow), tile display
`motionHud.js`	Tilt β/γ from `DeviceOrientation` for the right vertical tape HUD
`motionStabilityLink.js`	Links tilt/shake to reticle/minimap parallax and notifications (including vibration)

Feedback & monitoring

File	Role
`liveHealth.js`	Lightweight live health monitoring (inference latency, consecutive failures, video stall) and HUD notifications
`audioFx.js`	Web Audio API for boot, detection, lock-on, error sounds, etc.

`src/` — tests only (not used on screen)

File	Role
`lockTrackKeys.test.js`	Unit tests for `lockTrackKeys.js`
`liveHealth.test.js`	Unit tests for `liveHealth.js`
`tfBackend.test.js`	Unit tests for `tfBackend.js`

Dependencies (overview)

flowchart TB
  index[index.html] --> main[main.js]
  main --> config[appConfig / applyDevConfig / uiLexicon]
  main --> cam[camera + HUD]
  main --> det[personDetection]
  main --> face[facePrivacy]
  det --> tf[tfBackend]
  face --> tf
  main --> map[miniMap]
  map --> leaf[miniMapLeaflet]
  main --> nav[compass / motionHud / motionStabilityLink]
  main --> range[objectRange]
  range --> xr[webxrHitTestRange]
  main --> health[liveHealth]
  main --> sfx[audioFx]

main.js ties almost everything together; appConfig.js settings and uiLexicon.js copy drive behavior and display across modules.

Closing — What to Read Next

Future posts will open the source and go deep feature by feature. The study roadmap below is the planned reading order (01 is done with this article's file map).

Source reading roadmap (32 parts — click to expand)

Stage 1 — Config and skeleton (no permissions needed)

#	Title / theme	Main files	Core tech	Common pitfalls
01	~~Full map — roles in `src/`~~	~~`-`~~	~~Which file owns what~~	~~Memorizing filenames without reading code~~
02	`devConfig` — behavior remote control	`appConfig.js`	Camera, detection, CRT key meanings	One change affects the whole app
03	Single source for UI copy — `uiLexicon`	`uiLexicon.js`, `index.html`	Centralized strings and error messages	Finding leftover hardcoded text
04	CRT tokens to CSS — `applyDevConfig`	`applyDevConfig.js`, `style.css`	JS config → CSS variables (`:root`)	Typo in variable name breaks styles
05	HTML skeleton — splash & HUD DOM	`index.html`	Layer stack (video / canvas / HUD)	`z-index` vs `hidden` attribute

Stage 2 ⭐⭐ — Look and boot "theater" (testable without camera)

UI animation and audio control without device permissions.

#	Title / theme	Main files	Core tech	Common pitfalls
06	Splash, BIOS, scramble text	`main.js`, `style.css`	First-run UI flow, timer control	Duplicate timers, garbled text
07	Boot overlay — progress and steps	`main.js`	Async status during startup	Failed step never transitions to `error`
08	Web Audio — play after click	`audioFx.js`	`AudioContext` and user gesture	Autoplay policy, silent bugs
09	Reticle SVG and fixed layout	`index.html`, `style.css`	Center-fixed CSS layout	Why `motionStabilityLink` was disabled
10	Live HUD frame and CRT noise	`style.css`, `main.js`	Scan-line effects over video	Rendering cost of noise `canvas`

Stage 3 ⭐⭐⭐ — Media, sensors, tapes (real device required)

#	Title / theme	Main files	Core tech	Common pitfalls
11	Camera — `getUserMedia` and rear preference	`main.js`	`facingMode`, stream acquisition	iOS permission timing, connection hang
12	Video presentation — `object-fit: cover`	`style.css`, `main.js`	Hidden → visible preview transition	Unintended camera zoom
13	Full boot sequence — `startCamera`	`main.js`	After tap: camera → model load	Failure logs when changing parallel vs sequential
14	Heading tape — continuous angle and N jump	`compass.js`, `main.js`	0°–360° unwrap, SVG control	Clipping at north (N), insufficient padding
15	Tilt tape — β / γ and `motionHud`	`motionHud.js`, `main.js`	DeviceOrientation	`deviceorientationabsolute` behavior differences
16	Altitude tape — GPS altitude callback	`miniMap.js`, `main.js`	Geolocation API	Devices where altitude is `null`
17	Minimap — Leaflet and OSM/CARTO	`miniMap.js`	External tile map, marker	Handling location denial
18	Speed HUD — km/h from `coords.speed`	`miniMap.js`	Speed from coordinate changes	Speed shows `--` when stationary

Stage 4 ⭐⭐⭐⭐ — Detection, privacy, ML

#	Title / theme	Main files	Core tech	Common pitfalls
19	TF.js backend — WebGPU→WebGL→CPU	`tfBackend.js`	Graphics API fallback	Unsupported devices, first compile, heat
20	COCO-SSD intro — `ensureModel` and throttling	`personDetection.js`	Model load, inference throttling	CDN load failure, dynamic `import()`
21	Detection box drawing — `drawVideoCover` and canvas	`personDetection.js`	Drawing aligned to `video` aspect	Coordinate drift, DPR
22	Lock-on — zone, dwell, key stabilization	`personDetection.js`	Tracking ID, smoothing	ID swaps, flicker
23	Distance — WebXR hit-test only	`objectRange.js`, `webxrHitTestRange.js`	Measured distance on HUD	No distance on unsupported devices
24	Face mosaic — BlazeFace and canvas compositing	`facePrivacy.js`	rAF + throttled inference	Draw cycle vs inference collision
25	Mosaic interval and heat — `intervalMs`	`facePrivacy.js`	Inference FPS vs load tradeoff	Device freeze, thermal throttling

Stage 5 ⭐⭐⭐⭐⭐ — Integration, ops, errors

#	Title / theme	Main files	Core tech	Common pitfalls
26	Live health — latency, video stall	`liveHealth.js`	Main-thread stall monitoring	False positives under load spikes
27	Startup error handling — timeout and `catch`	`main.js`	Async error gaps	Model load timeout
28	Second visit and cache	`vite.config.js`	PWA, Vite build	`failed to fetch dynamically imported module`
29	Revisit and restart — model disposal	`main.js`	Memory leak prevention	Second run extremely heavy
30	`motionStabilityLink` — why parallax was cut	`motionStabilityLink.js`	Parallax vs readability	Janky rendering
31	Integration — `main.js` orchestration	`main.js` (full)	Lifecycle management	Tight coupling breaks on touch
32	Retrospective — bug list and what's next	App overall	Settling on load mitigation	Defining "fatal bugs are gone"

The next post will start with roadmap #02 (appConfig.js).

Episode 0: Deconstructing a Vibe-Coded Web App — 32 Steps From Black Box to Mine

Katsuo Imai — Fri, 22 May 2026 12:06:24 +0000

Episode 0: Turning a “Vibe-Coded” Black Box Into My Own App — A 32-Step Deconstruction Roadmap

I built an advanced web app in a burst of vibe coding—leaning hard on AI (Cursor and the like)—and packed in face recognition, WebGPU, and mobile sensors (heading, tilt, GPS).

Near the finish line, load-related bugs showed up. Then it hit me: I don’t understand what the code is doing, or why the bugs exist. Is this really my app? That disconnect—and a kind of guilt—was strong.

So I’m treating this black-box app as the best textbook I have: break it apart, learn the mechanics from the ground up, and turn it into real skill. This post is the index for that deconstruction journal.

Live deploy (for verification): Proto Recon (Cloudflare Workers)
Repository: github.com/katsutoshi0katsutoshi/proto_recon
Extracted experiments: CodePen / @wlzpaovm-the-bashful

🧭 Deconstruction roadmap (5 phases / 32 steps)

To avoid burning out, the order starts with low-dependency pieces—config and UI polish—and ramps up toward hardware control and ML / performance. Anything that can stand alone gets a minimal CodePen (or similar) as we go. (This plan was also AI-assisted.)

Phase 1 ⭐ — Map & settings (learn by touching)

First: the big picture of the codebase, then how static config and copy steer the whole app.

#	Title / theme	Main files	What you learn (core tech)	Common errors & traps
01	Big picture — roles under `src/`	`-`	Which file owns what	Memorizing filenames without reading bodies
02	`devConfig` — remote control for behavior	`appConfig.js`	Keys for camera, detection, CRT	One change ripples everywhere
03	Single source for UI copy: `uiLexicon`	`uiLexicon.js`, `index.html`	Centralized strings & errors	Finding leftover hard-coded text
04	CRT tokens into CSS — `applyDevConfig`	`applyDevConfig.js`, `style.css`	JS config → CSS variables on `:root`	Typo in var name → styles silently fail
05	HTML skeleton — splash & HUD DOM	`index.html`	Layers (video / canvas / HUD)	`z-index` vs the `hidden` attribute

Phase 2 ⭐⭐ — Look & boot “theater” (no camera permission needed)

UI animation and audio you can verify without device permissions—pure front-end.

#	Title / theme	Main files	What you learn (core tech)	Common errors & traps
06	Splash, BIOS, scramble text	`main.js`, `style.css`	First-run UI flow & timers	Double-started timers, garbled text
07	Boot overlay — progress & steps	`main.js`	Async status during startup	Failed steps never move to `error`
08	Web Audio — play after click	`audioFx.js`	`AudioContext` & user gesture	Autoplay policy, silent output
09	Reticle SVG & fixed layout	`index.html`, `style.css`	Center-fixed CSS layout	Why `motionStabilityLink` was cut
10	Live HUD frame & CRT noise	`style.css`, `main.js`	Scanline overlay on video	Noise `canvas` render cost

Phase 3 ⭐⭐⭐ — Media, sensors & tapes (real device required)

Core Web APIs: camera, gyro, GPS.

#	Title / theme	Main files	What you learn (core tech)	Common errors & traps
11	Camera — `getUserMedia` & rear preference	`main.js`	`facingMode`, stream acquisition	iOS permission timing, hung connections
12	How video is shown — `object-fit: cover`	`style.css`, `main.js`	Hidden → visible preview	Unintended “zoom” on camera feed
13	Full boot sequence — `startCamera`	`main.js`	Tap → camera → model load	Failures when parallel vs sequential order changes
14	Heading tape — continuous angle & N jump	`compass.js`, `main.js`	0°–360° unwrap, SVG control	Clipping at north (N), insufficient padding
15	Tilt tape — β / γ & `motionHud`	`motionHud.js`, `main.js`	Device tilt (`DeviceOrientation`)	`deviceorientationabsolute` differences
16	Altitude tape — GPS altitude callback	`miniMap.js`, `main.js`	Geolocation position & altitude	`altitude` is `null` on some devices
17	Mini map — Leaflet & OSM/CARTO	`miniMap.js`	External tiles, markers	Handling denied location
18	Speed HUD — `coords.speed` to km/h	`miniMap.js`	Speed from geo updates	Speed shows `--` while stationary

Phase 4 ⭐⭐⭐⭐ — Detection, privacy & ML backend (hardest)

The app’s main bottleneck—and the exciting part: real-time ML in the browser (TensorFlow.js).

#	Title / theme	Main files	What you learn (core tech)	Common errors & traps
19	TF.js backend — WebGPU → WebGL → CPU	`tfBackend.js`	Graphics API fallback chain	Unsupported devices, first compile, heat
20	COCO-SSD intro — `ensureModel` & throttling	`personDetection.js`	Model load, inference throttling	CDN load failure, dynamic `import()`
21	Detection boxes — `drawVideoCover` & canvas	`personDetection.js`	Canvas aligned to `video` aspect	Coordinate drift, device pixel ratio (DPR)
22	Lock-on — zones, dwell, key stabilization	`personDetection.js`	Track ID retention, smoothing	ID swapping, flicker
23	Distance display — bbox estimate & WebXR	`objectRange.js`	Pseudo-range from bounding box	Fallback when WebXR unavailable
24	Face mosaic — BlazeFace & canvas composite	`facePrivacy.js`	`requestAnimationFrame` + throttled inference	Camera draw vs inference cycle collision
25	Mosaic interval & heat — tuning `intervalMs`	`facePrivacy.js`	Inference FPS vs device load	Freeze / thermal runaway when FPS too high

Phase 5 ⭐⭐⭐⭐⭐ — Integration, ops & errors (toward production quality)

Bugs that appear when parts are wired together—including the ones I’m hitting now—and finishing the app as a whole.

#	Title / theme	Main files	What you learn (core tech)	Common errors & traps
26	Live health — stall & frozen video detection	`liveHealth.js`	Main-thread stall monitoring	False positives under load, retry loops
27	Startup errors — timeout & `catch`	`main.js`	Orphan async work, stream cleanup	Timeouts on huge model loads
28	Second visit & cache — asset deploy	`vite.config.js`	PWA cache, Vite build	`failed to fetch dynamically imported module`
29	Revisit & restart — stop & dispose models	`main.js`	Leak prevention, releasing instances	Second launch much heavier than first
30	`motionStabilityLink` — why parallax was cut	`motionStabilityLink.js`	Parallax vs readability	Jank when performance drops
31	Integration pass — `main.js` orchestration	`main.js` (whole file)	Module lifecycle	“Touch anything, break everything” coupling
32	Retrospective — bugs fixed & what’s next	App-wide	Load fixes, skills that stuck	Defining “fatal bugs are gone”

🛠️ How I’ll actually move forward

Taken seriously, 32 steps at one post per day is roughly a month; realistically, one or two posts per week means six months or more. It’s not an obligation—I’ll go at an easy pace, sitting down properly for each piece. I’ll still use AI to polish prose and to help draft posts.

I’ve tasted the fun of AI-assisted idea generation. On purpose, I’m now dismantling this heavy mock—using AI to push ideas to the max, then learning backward until I can rebuild them with my own hands.

Minimal slices go into CodePen as a collection. Months from now, when this index is full of links and I can explain the bugs in my own words, the app should finally be mine in name and in fact.

I’m already close to losing heart while writing this. I assume AI will upgrade fast enough that parts of this article feel dated. Episode 0 is here—will Episode 1 actually show up? I don’t know yet. But that’s the bet.

What I Learned Shipping TightTimeLog: AI Workflow, CSP, AdSense, and Distribution

Katsuo Imai — Mon, 20 Apr 2026 02:36:34 +0000

I built and launched TightTimeLog—a small offline-first PWA timer with bilingual UI and on-device logs—as a solo project. Along the way I hit AdSense rejection, underwhelming distribution experiments, and plenty of CSP surprises. This post bundles several shorter notes I published on my Hatena blog into one English piece for DEV.

Introduction

TightTimeLog was my first “ship it” personal project: PWA behavior, EN/JA UI, IndexedDB logs, and a focus on keeping data on the user’s device. Google AdSense did not approve the site (at least on the attempts I made), and marketing pushes did not move the needle as much as I hoped. Still, finishing deployment and seeing where things break was more valuable than the binary pass/fail. Below I split lessons into engineering, AI-assisted workflow, and distribution / monetization mindset.

1. Building with Cursor + Cloudflare Pages (and what hurt)

Why this stack

Cursor: conversational coding, refactors, and research in one loop—huge for a solo dev’s throughput.
Cloudflare Pages: static deploy + HTTPS + CDN with minimal ops—great default for a hobby site.

PWA and a little differentiation

I added haptic feedback on supported phones so the app feels slightly more “app-like” than a bare timer page. It’s a small touch, but it matches the goal of a pleasant mobile experience.

Design upfront

Using Figma early for icons and layout reduced late rework. For side projects, investing a bit in visuals before features explode pays off.

2. Practical prompting for i18n and “legal-ish” drafts (Cursor / Gemini)

i18n

The trick was to pin down library assumptions, output shape, and file layout in the prompt instead of saying “make it multilingual.” For example:

Externalize all user-visible strings; keep English and Japanese keys consistent with the existing app.js i18n object pattern; don’t leave hard-coded copy in HTML.

Fewer surprises, fewer round trips.

Privacy policy drafts

I listed facts only:

Where data lives (e.g., IndexedDB, not uploaded)
Third parties involved (hosting, contact form, ads if any)
How users can reach me

Then I edited the draft manually. AI reduces blank-page time; it doesn’t replace responsible review.

3. Cloudflare Pages + CSP: when “it worked locally” dies in production

Production Content-Security-Policy headers blocked third-party scripts and iframes I hadn’t allowlisted—especially after adding AdSense-related domains. Fixing it meant evolving _headers until the live response headers matched what the browser needed.

Mental model

/*
  Content-Security-Policy: default-src 'self'; script-src 'self' https://pagead2.googlesyndication.com ... ; frame-src https://googleads.g.doubleclick.net ... ;

Your exact directive will differ by which services you embed. I treated the browser console’s CSP violations as the source of truth for what to add.

Checklist I wish I had on day one

Inspect Content-Security-Policy on the real origin (not file://).
Watch the console for CSP violations after each new script or embed.
After changing _headers, re-deploy and confirm headers changed (avoid stale SW caches during testing).
When using a service worker, bump cache versions or test in a clean profile if HTML responses look “stuck.”

4. AdSense rejection: my self-analysis (non-legal, non-official)

Google doesn’t owe us a precise reason, but my working theory:

The product was optimized to be minimal UI copy, which can look like thin content to automated review.
Policy also cares about where ads appear—navigation-only or low-value shells should not carry ads.

I responded by adding original explanatory copy on main screens and keeping ad tags off purely supplementary pages. Monetization-wise, I’m treating AdSense as one experiment, not the only path.

5. Posting on Qiita, X, and Product Hunt: distribution lessons

Rough outcomes

X: posting cold from a fresh account barely moved traffic. I skipped community building (hashtags, consistent presence) and paid for it.
Qiita & Product Hunt: dropping a link alone didn’t create sustained traffic.

Takeaways

Context beats bare links—show up where your audience already discusses problems you solve.
Even tiny reactions matter; they’re fuel when metrics are flat.

Next, I want to lean into Build in Public: share the process, not only the launch URL.

Closing

Shipping still beat not shipping. I’ll keep iterating on TightTimeLog and experiment with other projects too.

Japanese dev diary: Hatena Blog.

Personal learning log—not legal or financial advice. Verify policies and products for your own situation.

DEV Community: Katsuo Imai

Building PROTO RECON — From Vague Idea to a Browser-Based Tactical HUD

Introduction

Where It Started

Technology Choices (Before Implementation)

Requirements at the Time (Summary)

Core Concept

Plan vs. Current State

How Development Proceeded

Source Layout

HTML (root level)

src/ — runtime files

Entry, config, UI

Video & AI inference

Distance & AR

Navigation, map, sensors

Feedback & monitoring

src/ — tests only (not used on screen)

Dependencies (overview)

Closing — What to Read Next

Stage 1 — Config and skeleton (no permissions needed)

Stage 2 ⭐⭐ — Look and boot "theater" (testable without camera)

Stage 3 ⭐⭐⭐ — Media, sensors, tapes (real device required)

Stage 4 ⭐⭐⭐⭐ — Detection, privacy, ML

Stage 5 ⭐⭐⭐⭐⭐ — Integration, ops, errors

Episode 0: Deconstructing a Vibe-Coded Web App — 32 Steps From Black Box to Mine

Episode 0: Turning a “Vibe-Coded” Black Box Into My Own App — A 32-Step Deconstruction Roadmap

🧭 Deconstruction roadmap (5 phases / 32 steps)

Phase 1 ⭐ — Map & settings (learn by touching)

Phase 2 ⭐⭐ — Look & boot “theater” (no camera permission needed)

Phase 3 ⭐⭐⭐ — Media, sensors & tapes (real device required)

Phase 4 ⭐⭐⭐⭐ — Detection, privacy & ML backend (hardest)

Phase 5 ⭐⭐⭐⭐⭐ — Integration, ops & errors (toward production quality)

🛠️ How I’ll actually move forward

What I Learned Shipping TightTimeLog: AI Workflow, CSP, AdSense, and Distribution

Introduction

1. Building with Cursor + Cloudflare Pages (and what hurt)

Why this stack

PWA and a little differentiation

Design upfront

2. Practical prompting for i18n and “legal-ish” drafts (Cursor / Gemini)

i18n

Privacy policy drafts

3. Cloudflare Pages + CSP: when “it worked locally” dies in production

Mental model

Checklist I wish I had on day one

4. AdSense rejection: my self-analysis (non-legal, non-official)

5. Posting on Qiita, X, and Product Hunt: distribution lessons

Rough outcomes

Takeaways

Closing

`src/` — runtime files

`src/` — tests only (not used on screen)