Keep Batch Deletes Inside the Persistence Boundary
Repair a batch deletion path that depended on a read projection by loading persistence models directly, validating the full batch, and returning the real transaction result.
01Fichil · Engineering Field Notes
Trace the failure. Keep the evidence.
Production systems, delivery pipelines, and enterprise integration—from symptom to verification.
Explore bilingual investigations grounded in logs, database state, tests, and release results. Each note explains what changed, why it changed, and how the real system boundary was verified.
From system signal to exact release
OBSERVE
Capture reproducible runtime signals.
ISOLATE
Narrow the real failure boundary.
VERIFY
Confirm the repair with reviewable evidence.
RELEASE
Deliver the exact reviewed commit.
52bilingual engineering notes
Open sourcesite repositoryCI + exact SHArelease evidence02Blog
Latest Engineering Notes
Recent field notes from debugging, backend work, DevOps, and AI-assisted development.
Fixing Today-Only Metrics with Explicit Day Boundaries
Repair a metric labelled today that included the previous day by defining one local-day interval, isolating headline parameters, and reconciling the total with its detail population.
Deriving Workflow Status from Real Transition Evidence
Repair a workflow report that advances too early by filtering invalid events, normalizing legacy stages, recovering from business evidence, and recording milestones only when transitions occur.
03Signal index
Follow the systems you work with.
Move through the notebook by engineering domain, from production debugging to delivery and integration.
04Services
Problems I Can Help Close
Focused engineering support for systems that are difficult to diagnose, risky to change, or spread across several teams and services.
01
Production Reliability & Performance
Trace failures through logs, runtime configuration, database behavior, dependencies, and resource limits; make the smallest safe change and prove the result.
Incident AnalysisSQL PerformanceRuntime
02
DevOps & Delivery Engineering
Make builds, CI checks, environment boundaries, release evidence, and rollback paths repeatable without hiding operational risk behind automation.
CI/CDDockerRelease Safety
03
Enterprise Logistics Integration
Align identity, contracts, state transitions, idempotency, reconciliation, and failure handling across WMS, TMS, YMS, SAP/ERP, carriers, billing, and OpenAPI.
WMS/TMS/YMSSAP/ERPOpenAPI
05Core Cases
Selected Engineering Cases
Public, source-backed examples showing how I diagnose, change, and verify complex systems without exposing client identities or private data.
01Reliability
SQLPerformanceProduction
Production Reliability & Performance
A production dashboard showed zero while business data existed. The request path loaded large detail sets into Java, timed out, and left the UI's default value visible as if it were real data.
Change scope
- Trace the request from UI state through Java queries and production data volume
- Move summary calculation into database aggregates without changing the API contract
Verification evidence
- Reconciled old and new results with read-only checks
- Made failures visible instead of presenting them as valid zeroes
02Open Source
Open SourceAI-AssistedSites
AI-Assisted fichil.com
This site is an open-source delivery system: Hugo Markdown remains the content source, vinext renders the Sites application, and validated changes move through CI, exact-SHA release evidence, and version-based rollback.
Change scope
- Bilingual content and application changes remain reviewable in Git
- People define release policy; protected checks can auto-merge narrowly scoped blog updates
Verification evidence
- The deployed commit is exposed through /version.json
- Production rollback uses a previously known-good Sites version
03Integration
WMS/TMS/YMSSAP/ERPReconciliation
Enterprise Logistics Integration
Integration work across WMS, TMS, YMS, SAP/ERP, carriers, billing, proof of delivery, and OpenAPI requires more than connecting endpoints: identity, ownership, state, retry, and reconciliation rules must agree.
Change scope
- Define contracts, ownership boundaries, state mappings, idempotency, and error semantics
- Close inbound, inventory, outbound, transport, billing, yard, and external API flows
Verification evidence
- Verify final state through database reconciliation and full-domain smoke scenarios
- Keep unavailable third parties outside the platform's internal acceptance decision
06Working method
An Open, Reviewable Way of Working
I use this site as both an engineering notebook and a public record of how I work. Each useful case starts from observed behavior, follows the real data and runtime path, limits the change surface, and ends with verification.
- Evidence before edits: logs, process arguments, database state, network paths, and reproducible failures.
- Small, reversible changes: preserve existing contracts and parallel business flows unless the requirement explicitly changes them.
- Verification at the real boundary: reconcile data, test retries and failures, build release artifacts, and confirm the deployed version.
- AI-assisted, policy-gated: people define the delivery policy and remain accountable; narrowly scoped bilingual blog PRs may auto-merge only after protected checks, while other changes remain human-reviewed.
Core Stack
01Java / Spring / REST APIs
02MySQL / SQL troubleshooting
03Linux / Runtime / Networking
04Docker / GitHub Actions
05WMS / TMS / YMS / SAP integration
06Codex / AI-assisted engineering
07Contact
Describe the System, Not Just the Symptom
For production troubleshooting, DevOps delivery work, or logistics integration, send the current behavior, expected result, affected environment, available logs or data samples, and any release constraint. I will respond from the evidence that is actually available.
Start with an Email