Work

Selected work showing how I separated and verified complex flows across web and mobile apps, Android devices, and production delivery.

Selected Work

01BuildWeb / Mobile2026.04 ~ 2026.06

Logistics Operations and Output Flow

Connected lookup, reservation, Excel, and label output across web and mobile-device boundaries.

Scope

New build and output integration

Operations / WebView and Android output

Technology stack

Web

React
TypeScript
Vite
React Router
TanStack Query
Zustand
XLSX
Vitest

Mobile

Expo
React Native
Expo Router
WebView
Android native module
TypeScript
Bluetooth

Problem

Reservation intake, batch work, Excel preview, and output belonged to one workflow, but desktop browsers and mobile devices lived in separate apps and repositories with different runtime constraints. Web loading cost and Android permission, Bluetooth, and printer-SDK behavior needed separate boundaries while sharing request data and failure criteria.

Key decision

The web app owned lookup, reservation, Excel, output-request state, and initial loading, while mobile owned permissions, Bluetooth, and printer output after the WebView contract.

Web

2026.04 ~ 2026.06

Logistics Operations Web

The work connected API integration, responsive UI, spreadsheet handling, and print paths under the same operational baseline.

Mobile

2026.04 ~ 2026.06

Mobile Output Bridge App

The app kept the business screen in WebView while moving device-specific output responsibilities into a native module boundary.

Verified outcome

Verified web entry cost and mobile output completion against separate runtime and validation criteria.

Logistics Operations Web

web initial JS entry: 2,405.50 → 616.59 kB; About 74% lower after route and spreadsheet lazy loading
web gzip size: 815.10 → 204.38 kB; About 75% lower for the same initial entry

Mobile Output Bridge App

mobile output check: Android 16 / API 36; Permissions, Bluetooth connection, and physical label output checked

Working principle

Even one user journey needs separate completion criteria for browser performance and physical-device output.

Implementation and verification details

Presented a React operations web app and a mobile output app from separate repositories as one user workflow while keeping screen-state and device-SDK responsibilities distinct.

Web

Logistics Operations Web

2026.04 ~ 2026.06Operations / Performance

Problem

Bundling initial screens with spreadsheet handling made the first load heavy, while mixing desktop and WebView print paths made verification unclear.

Decision

Separated data integration, UI state, and print-request boundaries before adding more screens.
Moved non-initial routes and spreadsheet processing to runtime-loaded paths.
Treated desktop print, mobile browser fallback, and WebView/native output as separate flows.

Solution

Built the main workflows on a shared shell, table, modal, form, and feedback structure.
Connected reservation intake, bulk handling, contact selection, Excel preview, and print payload conversion.
Applied route-level lazy loading and spreadsheet-library lazy loading from bundle analysis.

Execution

Connected lookup, reservation, contact, spreadsheet, and print flows inside the same shell first.
Separated mock data from the API adapter so UI state and integration state could be checked independently.
Split print verification across formatter, preview, browser fallback, and native request paths.
A deeper app, auth, public-API, and UI split reached 500.67 kB (164.69 kB gzip), but was rejected because added auth/API initialization and first-click loading boundaries outweighed the gain.
The accepted lazy-loading scope was checked across 116 files and 573 tests; the physical PC label path was checked separately across 8 files and 73 tests.

Impact

Initial JS entry: ~74% lower; non-initial routes and spreadsheet handling were split out
gzip size: ~75% lower; same-baseline first-load reduction
Responsive checks: mobile to desktop; mobile, tablet, and desktop width baseline

Checks

Checked overflow, modal clipping, and dropdown placement across key viewport widths.
Checked formatter, bitmap, command, and browser fallback paths as print regressions.
Re-ran lint, test, build, and bundle analysis to separate accepted optimization from experiments.

Mobile

Mobile Output Bridge App

2026.04 ~ 2026.06WebView / Android native module

Problem

Sending a print/output request from a web button is different from making the physical mobile device complete it. WebView, permission, native module, and device state needed separate failure boundaries.

Decision

Kept the business screen in the web layer and moved device-facing output into the native module.
Handled WebView bridge requests and native responses as structured contracts.
Separated development and production URLs, app identifiers, and install artifacts.

Solution

Organized the request/response path between the WebView bridge and Android native module.
Separated payload conversion, device-state checks, and failure messaging.
Kept mobile browser fallback distinct from app WebView output.

Execution

Defined the boundary that converts web output data into a native output payload.
Checked Bluetooth permission, device lookup, connection state, and output command stages.
Separated local development, test install, and production install conditions.
Traced the SDK's internal device-discovery call on Android 16/API 36 and added cancellation plus BLUETOOTH_SCAN and BLUETOOTH_CONNECT handling.
Treated command-queue acceptance and completed physical output as separate verification points.

Impact

output boundary: WebView -> native; web payload separated from device output commands
device output: real device check; verified against Android device behavior, not only emulator flow

Checks

Checked permission, device connection, and output request flows on an Android device.
Checked that WebView bridge requests and native output responses stayed separated.
Checked development and production install baselines.

02BuildWeb2026.03 ~ 2026.04

Structured Chart Editing UI

Designed an editing flow that kept data roles and settings aligned with the rendered preview.

Scope

Editor feature implementation

Visualization / editor UI

Technology stack

React
TypeScript
Vite
Chart.js
WebGL/GLSL (OpenGL-style)
OGL (WebGL library)
MSW
Vitest

Problem

Forcing every option onto every chart type makes the settings UI noisy, and if preview and panel state drift apart users cannot trust the current result.

Key decision

Showed only valid options for each chart type and separated field mapping, preview lifecycle, and settings state around one editing model.

Verified outcome

Connected settings state and the rendered preview under one regression scope to check that the editing flow stayed aligned.

mapping · preview · settings: state alignment; kept selected data roles and settings connected to the rendered result
mixed-chart preview: fewer remount conditions; limited to reducing unnecessary remounts and scroll movement

Working principle

Editor trust comes from keeping input state aligned with the rendered result, not from offering more options.

Implementation and verification details

Replaced a limited hand-built preview with Chart.js and separated field mapping, preview lifecycle, and chart-specific settings responsibilities.

Problem

Forcing every option onto every chart type makes the settings UI noisy, and if preview and panel state drift apart users cannot trust the current result.

Decision

Showed only valid option groups for the current chart type.
Tracked data mapping, preview rendering, and settings state independently.

Solution

Structured a six-area settings panel and preview flow.
Reduced mixed-chart remount conditions to lower flicker and scroll movement.

Execution

Aligned chart type, field mapping, preview, and option panels into one editing flow.
Reduced cases where setting changes unnecessarily remounted the preview.
Built editor background modes with WebGL/GLSL fragment shaders and OGL.
Checked portal help, drag overlays, loading/empty/error states, and renderer boundaries separately.

Impact

settings structure: 6-tab panel; chart settings separated by editing area

Checks

Checked preview rendering, option changes, panel collapse, drag/drop, and tooltip flows.
Checked related tests, lint, and build.

03Internal toolTooling2026.04

AI-assisted Project Documentation Tool

Built a controlled workflow for source scanning and human review instead of treating AI output as final documentation.

Scope

Internal tool build

AI API / developer productivity

Technology stack

Node.js
TypeScript
React
AI API
Workbook UI
xlsx
Vitest

Problem

Passing unstructured material directly to a model can mix checked source material with guesses, and small revisions can cause the whole artifact to drift.

Key decision

Previewed deterministic scanner evidence before AI drafting, kept the workbook as the review record, and limited revisions to selected sheets and cells.

Verified outcome

Verified each stage from evidence collection through human review and scoped revision as a distinct path.

scanner → preview: evidence first; reviewed deterministic scan results before using them for AI drafts
human-readable artifact: workbook review; reviewed requirements, features, and screens as tables before export
sheet / cell context: scoped revision; sent the intended edit and preserved context instead of regenerating everything

Working principle

AI assistance should leave reviewable artifacts by keeping evidence input, human review, and scoped revision boundaries explicit.

Implementation and verification details

The tool turns kickoff material and repository scan results into requirement candidates, clarification questions, and feature/screen document drafts that can be reviewed as a workbook.

Problem

Passing unstructured material directly to a model can mix checked source material with guesses, and small revisions can cause the whole artifact to drift.

Decision

Collected rule-based scanner output before AI generation.
Used workbook JSON as the central model and treated markdown/export as derived output.
Kept automation at draft generation while preserving human review through table-based editing.

Solution

Connected run workflow, scanner output, preview, detail artifacts, logs, and export paths.
Made requirement, functional, and screen documents reviewable as workbook-style tables.
Sent target sheet/cell and preservation context together for revision requests.

Execution

Showed scan results as a preview before asking the user to rely on generated documents.
Split generated output into workbook sheets instead of leaving it as one long text block.
Scoped revisions to the selected sheet/cell context instead of regenerating the whole artifact.
Separated partial-failure manifests from current/history artifacts so successful output and failed runs remained traceable.
Separated fields AI could organize from decisions reserved for the user and suppressed unsupported placeholders.

Impact

generation input: Scan -> Preview; AI draft after rule-based scanning
reviewable output: xlsx workbook; requirements, features, and screens reviewed as tables
partial rewrite: Selected cell revision; rewrite scope reduced to selected sheet/cell context

Checks

Checked scanning, AI preview, workbook rendering, and export flows.
Checked selected sheet/cell revision while preserving existing workbook context.
Checked shared, engine, server, and web tests along with lint/build.

04MaintenanceHybrid2026.06 ~ 2026.07

Hybrid Life Information Service

Maintained external API, cache, location, and production rollout flows across legacy web and Android WebView.

Scope

Maintenance and production rollout

Legacy Web / Android WebView / Operations

Technology stack

Spring MVC
JSP
jQuery
Java
Android
Public API adapter
SHA-256

Problem

Multiple external APIs and reference-data lookups were tied to one request, so one slow section could delay the whole screen. File-level rollout also required missing-file and exposed-setting checks.

Key decision

Separated core and secondary loading, fresh and stale caches, and reference-data caches, then limited production delivery to manifest and SHA-256 hash scopes.

Verified outcome

Verified cache behavior, regression coverage, and dated production deliveries against separate baselines.

core production smoke: about 2.85s → 0.11s; cold request versus cache hit observed on 2026-07-08
air-quality production smoke: about 2.02s → 0.07s; cold request versus cache hit observed on 2026-07-08
final regression: 131 tests / 1 skipped; checked in the final mvn test; rollout verified separately by hash and smoke

Working principle

Legacy production improvements should record preserved contracts, fallbacks, and deployment evidence alongside the changed scope.

Implementation and verification details

Updated web and Android WebView behavior, then checked API responses, reference-data caches, and deployed files in production screens.

Problem

Multiple external APIs and reference-data lookups were tied to one request, so one slow section could delay the whole screen. File-level rollout also required missing-file and exposed-setting checks.

Decision

Separated immediately visible core information from secondary information that could load later.
Split fresh and stale cache so limited fallback could be shown when external APIs failed.
Narrowed operations rollout through manifest, hash, and smoke checks instead of broad replacement.

Solution

Built a core-first loading model with section-specific cache rules.
Prepared reference data as server cache with temporary-save, validation, and replace flow.
Used native location first in Android WebView, then stored location and browser fallback.

Execution

Separated external API calls, reference-data lookup, and location fallback by screen loading order.
Handled reference data through collect, temporary save, required-field validation, and replace steps.
Checked changed files and hashes before verifying the actual screen flow through smoke checks.
Prepared 673 air-quality stations and 20,560 legal-district rows as reference caches outside the request path.
Treated the 111-file rollout on 2026-07-02 and the 42-entry manifest rollout on 2026-07-08 as separate deployments and checks.
Automated reference refresh and catalog reduction remained follow-up work, while the JVM memory cache remained limited to one Tomcat instance.

Impact

reference-data cache: required-field checks; prepared as server cache with missing-value checks
region-resolution flow: fallback baseline; separated the fallback path for failed or delayed lookups
rollout checks: smoke baseline; checked changed files together with key screen flows

Checks

Checked reference-data collection results and required fields.
Compared cold request and cache-hit flows through smoke checks.
Verified file hashes and key screen flows for operations rollout.

Additional Work

Additional feature and maintenance work focused on change boundaries and regression baselines.

MaintenanceAndroid / Hybrid2026.03

Legacy Mobile App Compatibility

Technology stack

Android Java
Gradle/AGP
RxJava
FileProvider

Key decision

Did not treat a successful build and runtime compatibility as the same completion criterion.

Verified outcome

Gradle/AGP/JDK/SDK: build baseline restored; build-tool changes separated from target SDK and runtime behavior

Checked debug and release builds, IDE sync, and compile paths.

Implementation and verification details

Separated modern Android build-policy work from legacy runtime regression checks.

Stabilized an older Android hybrid app by treating the build chain, permissions and files, WebView bridge, login, and initial synchronization as separate failure boundaries.

Problem

The legacy Gradle and AGP setup no longer matched current development tools, while applying current SDK policies directly could introduce separate regressions in file access, permissions, services, back APIs, older OS entry, and WebView flows.

Decision

Kept modern API types and OS-specific permission or file behavior behind compatibility helpers instead of repeating checks in screens.
Separated login, initial synchronization, WebView navigation, and bridge errors into distinct failure channels.

Solution

Restored a compilable baseline without rewriting all remaining legacy support dependencies.
Encapsulated direct modern back-API references and file or permission branches inside helpers.
Normalized WebView bridge responses and asynchronous errors, with fallbacks that kept optional device or external-function failures from terminating the whole app.

Execution

Aligned Gradle, AGP, JDK, compile SDK, and module namespaces in stages.
Checked content URI, FileProvider, Bluetooth permission, scanner, and service-start conditions against OS policy changes.
Separated bridge null/error responses, asynchronous cleanup, login failures, and initial synchronization failures when narrowing regressions.

Impact

OS-specific behavior: compatibility boundary; permission, file URI, back API, and service calls isolated in helpers

Checks

Checked unit tests for compatibility helpers and bridge fallbacks.
Recorded real older-OS checks separately from items verified through static builds.

React rebuildWeb2026.03

Stock Operations Admin Web

Technology stack

React
TypeScript
Vite
React Router
TanStack Query
Zustand

Key decision

Grouped repeated table/filter/modal behavior into common primitives while leaving domain meaning at the screen level.

Verified outcome

server-state flow: React Query; shared baseline for screen-level fetch/update behavior

Checked table, filter, modal, and session flows at screen level.

Implementation and verification details

Rebuilt stock operations lists, filters, modals, and session flows in React from the existing business workflow.

Organized repeated admin flows such as lookup, search modals, detail checks, create/update, and status changes into shared structures.

Problem

In stock operations screens, direct DOM manipulation spreads change points as similar tables and modals grow, while shared concerns can become screen-by-screen exceptions.

Decision

Consolidated server data refresh through React Query and kept screen state separate.

Solution

Organized common table, filter, modal, and top-bar patterns.
Generalized repeated behavior such as column pinning/resizing, truncate tooltips, copy, and infinite scroll.

Execution

Collected repeated table, filter, modal, and top-bar behavior into shared baselines first.
Placed screen-specific columns, actions, and session flows on top of those baselines.

Feature extensionHybrid2026.06

Hybrid External Integration Enhancements

Technology stack

Android
Cordova
Spring MVC
jQuery
Java

Key decision

Kept external lookup responsibility inside a server-side proxy.

Verified outcome

credential boundary: server-side proxy; external integration responsibility kept outside the client

Checked that real credential values were not present in docs or sample settings.

Implementation and verification details

Kept external credentials out of the client by separating server proxy and WebView QA boundaries.

Organized the boundary between external integration, response normalization, image input, file picker, routes, and WebView bridge behavior.

Problem

Putting external credentials into an Android APK or browser JavaScript would expose them, and sending full external responses to the UI could leak unnecessary raw data.

Decision

Returned only the minimum result and state needed by the client UI.

Solution

Documented sample-setting and credential-search baselines.
Split file chooser behavior by input source and native picker flow.

Execution

Separated client input, server proxy, external response, and displayed result in order.
Checked WebView file chooser behavior by input source across emulator and real device flows.

Checks

Checked route, file chooser, tab sync, and bridge flows on emulator and real devices.

MaintenanceAndroid2026.03 ~ 2026.04

Field Terminal Android App

Technology stack

Android Java
Gradle/AGP
Scanner SDK

Key decision

Separated deployment signing conditions from whether local development builds could run.

Verified outcome

Gradle/JDK cleanup: build recovery; development build path separated from operational signing

Checked development and production build paths with the main entry flow.

Implementation and verification details

Separated operational signing from current build recovery so the field app could be verified again.

Recovered build and runtime flows for an Android app used on field devices, separating build tools, signing, login, initial data, and scan input checks.

Problem

When operational signing or old build assumptions block local builds, developers cannot verify features. Emulator-passing flows can also fail on field devices because of input timing.

Decision

Avoided treating build-tool updates and runtime behavior changes as one issue.

Solution

Separated signing conditions so development builds did not stop before verification.
Left device input behavior as a real-device verification item.

Execution

Narrowed build failures by Gradle, JDK, SDK, and signing condition.
Checked login, initial data, and scan input as separate stages.

Impact

scan/device flow: field input; login, initial sync, and input stages checked separately

Checks

Checked scan input and initial data flow by stage.

Impact analysisLegacy Web2026.06

Legacy Web Panel Split Baseline

Technology stack

JSP
jQuery
Server-rendered web

Key decision

Separated target and non-target areas first, then distinguished existing defects from new regressions.

Verified outcome

pre-change mapping: impact map; selector, popup, loader, and contract risks separated

Checked browser access baseline and page-loader behavior.

Implementation and verification details

Mapped coupling, API contracts, and browser baselines before splitting legacy screens.

Checked shared popups, selector prefixes, list state, page loaders, and backend parameter order before changing files.

Problem

Multiple menus and popup callbacks shared the same legacy scripts, so simply moving files could break nearby functions.

Decision

Kept backend parameters and upload/download contracts unchanged for the split scope.

Solution

Prepared an impact matrix, API contract notes, manual verification runbook, and runtime baseline.
Recorded static-search targets and stop signals before implementation.

Execution

Checked shared popups, selector prefixes, page loaders, and backend parameters as impact points.
Recorded manual verification runbook and stop signals before splitting source files.