33 KiB
33 KiB
外部顾问审阅全景资料包：blog.hoelee.com 候选文章改写与 LinkedIn 发布审核（第二批新选文章 - 已审阅已排期）
文档状态：外部技术品牌与高端招聘顾问已全量逐字审阅完毕。 处理进展：所有 10 篇候选文案均已按顾问诊断意见完成微调与求职红线脱敏，并正式录入 NocoDB（Base:
Hoelee Career Agent）草稿箱（status = APPROVED），进入 5 周平稳排期发布阶段。
一、 战略背景与核心业务目标（顾问审阅基准）
博客网站 blog.hoelee.com 与 LinkedIn 个人主页是作者（Lee Teong Hoe）技术实力与职业品牌的双核阵地。所有发布到 LinkedIn 的内容必须精准协同以下两大核心目标：
1. 最高优先级：高端技术求职招聘（Senior 全栈 / DevOps / AI 平台架构师）
- 目标画像：面向 6-10 年经验的远程（Remote）或本地/混合（Hybrid）资深全栈工程师、平台工程师、DevOps/SRE 负责人及 AI 智能体应用架构师岗位（偏好具备 Series A/B+ 轮成长型团队）。
- 【最关键职业红线】绝不可把自己写成“做生意的老板/创业创始人/数字游民中介 (Founder/Business Owner/Agency Lead)”：
- 在企业 HR、猎头与工程 VP 的初筛逻辑中，如果动态充斥“我在做生意”、“我的客户代理模式”、“我的数字商品电商”等自述，候选人会被直接判定为“有个人买卖、无法全职全身心投入企业雇佣”，在第一轮即遭淘汰。
- 强制转换规范：所有涉及真实商业落地的项目，必须从**“生产系统研发与高可用保障”、“为企业客户交付的生产级工程项目”、“自建自动化运维体系”**的技术架构视角切入。突出状态机设计、数据流可靠性、异常排查与系统韧性，展现资深雇员与技术专家的专业交付深度。
2. 次要目标：B2B 中小企业技术咨询与私有化高可靠交付（Freelance & Advisory）
- 面向需要自托管私有化系统、高吞吐媒体管线、自动化 AI 智能体、高可用邮件及反代基础设施的中小企业与技术团队。
- 动态必须通过真实的工程复盘展示“不可伪造的实操硬实力（Proof of Expertise）”，让潜在客户感知到作者解决复杂生产疑难杂症的确定性与工程可靠性。
二、 顾问核心诊断与修订落实总览
| 槽位 | 系统标识 Key | 拟发日期 | 顾问结论 | 核心修改与落地要点 |
|---|---|---|---|---|
| 01 | when-smart-says-healthy-but-your-raid-is-corrupting-data |
2026-10-29 (Thu) | 通过 (首发标杆) | 硬核存储取证标杆之作，CRC32C 零块推导严密，零违规，第一顺位标杆发布。 |
| 02 | slashing-agent-context-with-a-code-graph |
2026-11-03 (Tue) | 通过 | 零违规，数据边界清晰，展现一流 AI 平台架构功底，直接排期发布。 |
| 03 | running-production-infrastructure-solo |
2026-11-05 (Thu) | 通过（已微调） | 调整第 2 段表述，将无团队/不用 PaaS 转化为高密度单位经济效益与架构严谨度。 |
| 04 | the-single-writer-rule-for-coding-agents |
2026-11-10 (Tue) | 通过（已微调） | 优化倒数第三段逻辑，强调“结构性消除 Git 锁竞争与合并前捕获 100% 幻觉回归”。 |
| 05 | how-i-built-the-digikedai-telegram-bot |
2026-11-12 (Thu) | 需微调（已更新） | 消除电商副业色彩，强化 B2B 多租户权限开通与高可靠网关架构定位。 |
| 06 | your-disk-full-alert-is-lying |
2026-11-17 (Tue) | 需微调（已更新） | 纠正人称复数 our -> my，统一 PromQL 指标为 avail_bytes，规范字节表达式。 |
| 07 | jpa-version-field-lost-update |
2026-11-19 (Thu) | 需微调（已更新） | 补充 JPA 托管实体自动覆盖版本号的深坑解析，展现 Senior 代码审查功底。 |
| 08 | stop-writing-agent-prompts-for-deterministic-work |
2026-11-24 (Tue) | 需微调（已更新） | 补充挂载调度器背景与 125 行包含重试/去重/退避逻辑，立住工程克制力形象。 |
| 09 | why-telegram-bot-notifications-die |
2026-11-26 (Thu) | 需微调（已更新） | 补齐文末思辨提问；明确 extra_hosts 属于应急止血手段，展现网络协议排障能力。 |
| 10 | self-healing-digital-goods-entitlements |
2026-12-01 (Tue) | 需微调（已更新） | 脱敏数字商品电商词汇，全面升级为企业级多租户订阅与受控存储网关 IAM 授权架构。 |
三、 10 篇最终修订版文案全文（已入库 NocoDB 排期）
槽位 01. When SMART Says Healthy and Your RAID Is Silently Corrupting Data
- 系统标识 Key：
when-smart-says-healthy-but-your-raid-is-corrupting-data - 所属分类：
devops - 博客源文章：https://blog.hoelee.com/posts/when-smart-says-healthy-but-your-raid-is-corrupting-data/
- 排期规划：Wave 1 (立威期) | 拟发布时间:
2026-10-29 (Thu) - 顾问审阅结论：
通过— 硬核存储取证标杆之作，CRC32C 零块推导严密，零违规，第一顺位标杆发布。 - NocoDB 映射：Candidate Key
cand:when-smart-says-healthy-but-your-raid-is-corrupting-data/ Draft Keycand:when-smart-says-healthy-but-your-raid-is-corrupting-data:v1(status = APPROVED) - 正文字符数：1935 chars (符合 < 3,000 字符限制)
LinkedIn 拟发布动态最终修订稿：
Every hardware handbook gives you the same advice: monitor SMART attributes, inspect dmesg, and trust your drive controller.
In production, hardware can lie to you while reporting 100% health.
I managed a Btrfs RAID1 storage pool across two enterprise NVMe drives. SMART telemetry reported zero reallocated sectors, zero uncorrectable errors, and 100% remaining endurance. Yet a virtualized Windows production workload on that pool began throwing filesystem corruption errors.
When I ran checksum verification, Btrfs exposed the truth:
`btrfs: checksum verify failed on logical 104857600: wanted 0x4a12b3c1, found 0x8941f998`
That found checksum — `0x8941f998` — was the smoking gun.
In little-endian, `0x8941f998` is the exact CRC32C checksum of a 4 KiB block filled entirely with zeros (canonical: `0x98f94189`). The drives were not writing bitflips or bad magnetic sectors; the storage controller was returning clean, silent zero-blocks instead of persisted data.
The underlying root cause?
It was not bad flash chips. It was queued asynchronous TRIM (`discard=async`). Under sustained parallel I/O, the drive controller's garbage collection routine was executing queued deallocate commands prematurely against active mirrored blocks.
Key systems engineering takeaways:
• SMART only reflects internal drive health counters; it is completely blind to bus-level protocol bugs, PCIe riser signaling faults, and controller firmware race conditions.
• Only end-to-end checksumming filesystems (Btrfs, ZFS) can catch silent data corruption before it poisons backups.
• When diagnosing filesystem corruption, inspect the checksum hash mathematically — a zero-block signature points straight to deallocation, TRIM, or unmapped pages.
How do you detect silent data corruption in your storage arrays before customer data is compromised?
Write-up: https://blog.hoelee.com/posts/when-smart-says-healthy-but-your-raid-is-corrupting-data/
槽位 02. Slashing Agent Context and Token Churn With an AST Code Graph
- 系统标识 Key：
slashing-agent-context-with-a-code-graph - 所属分类：
ai - 博客源文章：https://blog.hoelee.com/posts/slashing-agent-context-with-a-code-graph/
- 排期规划：Wave 1 (立威期) | 拟发布时间:
2026-11-03 (Tue) - 顾问审阅结论：
通过— 零违规，数据边界清晰，展现一流 AI 平台架构功底，直接排期发布。 - NocoDB 映射：Candidate Key
cand:slashing-agent-context-with-a-code-graph/ Draft Keycand:slashing-agent-context-with-a-code-graph:v1(status = APPROVED) - 正文字符数：1995 chars (符合 < 3,000 字符限制)
LinkedIn 拟发布动态最终修订稿：
When you prompt an AI coding agent to modify a 50,000-line codebase, its default instinct is brute force: grep directories and recursively dump dozens of files into context.
The result is instant token bankruptcy:
• Reading 25 files to trace one dependency consumes 40,000+ tokens in a single turn.
• High-context saturation triggers cognitive degradation — models start hallucinating method signatures and missing subtle type contracts.
I tested three conventional fixes, and all of them failed under real development conditions:
1. Ripgrep keyword filtering: Zero semantic awareness. A search for `processOrder` matches comments, test mocks, and logging across 60 files. The agent still had to open 15 files just to find the implementation.
2. Vector RAG embeddings: Excellent for fuzzy concepts, useless for deterministic code trees. Vector similarity regularly misses internal helper functions (like `_verifyNonce`), leading agents to generate patches with nonexistent signatures.
3. File outline skeletons: Lacks parameter types and caller hierarchies, forcing speculative full-file reads anyway.
The durable fix: A pre-indexed AST Code Knowledge Graph.
Before the agent touches the code, an external parser extracts the repository's Abstract Syntax Tree into a symbol graph of callers, callees, definitions, and interface implementations.
• When the agent needs to inspect a function, it queries the graph and receives an exact 140-token node (signature, parameter types, caller list).
• Instead of dumping 3,000 lines of code across 5 files, the agent targets its read exclusively to the specific 25 lines that require mutation.
Across 20 production tickets, AST code graphs reduced agent context overhead by ~80% and eliminated 100% of signature hallucination errors.
How is your team balancing deterministic AST symbol graphs with semantic search when building context pipelines for coding agents?
Write-up: https://blog.hoelee.com/posts/slashing-agent-context-with-a-code-graph/
槽位 03. Running Production Infrastructure Solo: 162 Containers Across Three Hosts
- 系统标识 Key：
running-production-infrastructure-solo - 所属分类：
case-studies - 博客源文章：https://blog.hoelee.com/posts/running-production-infrastructure-solo/
- 排期规划：Wave 1 (立威期) | 拟发布时间:
2026-11-05 (Thu) - 顾问审阅结论：
通过（已微调）— 按顾问建议微调第 2 段，将无团队/不用 PaaS 转化为高密度单位经济效益与架构严谨度。 - NocoDB 映射：Candidate Key
cand:running-production-infrastructure-solo/ Draft Keycand:running-production-infrastructure-solo:v1(status = APPROVED) - 正文字符数：2223 chars (符合 < 3,000 字符限制)
LinkedIn 拟发布动态最终修订稿：
I run 162 Docker containers across three self-managed production hosts with 78 compose stacks — serving public client applications, mail infrastructure, workflow automation, and CI/CD pipelines.
Operating at that density without leaning on a sprawling ops team or five-figure managed cloud PaaS bills forces strict architectural discipline.
When you manage an estate of that density solo, you learn quickly that conventional dashboard metrics are dangerous. Two real-world production failures changed how I audit my systems:
1. The silent database dashboard disconnect
My analytics dashboard (NocoDB) was happily displaying rows and answering HTTP 200. Downstream, the background replication worker had dropped its database socket four hours earlier. The UI was serving cached metadata from memory while live mutations stalled. A green dashboard is not health; transactional read-after-write verification is health.
2. The zero-config daemon lockup
A credential management container hung on startup after a routine patch. Docker health checks passed because PID 1 stayed alive, but reverse-proxy requests timed out with HTTP 504. The culprit? An empty GPG keyring directory in a newly mounted volume triggered a blocking interactive entropy prompt inside the daemon. Health checks that probe process existence rather than live application handshakes will always deceive you.
My operational rules for running production infrastructure solo:
• Segregate workloads by isolation boundary: public ingress and edge routing live on a dedicated VPS; core storage and identity live behind private gateways.
• Telemetry must be completely decoupled from application runtimes.
• If an alert is based on an arbitrary percentage ratio instead of absolute time-to-exhaustion, delete it.
When you operate both the codebase and the host it runs on, there is no finger-pointing between the developer and the infrastructure provider. You own the transport layer as completely as the application layer.
For those running dense container footprints: what is your primary watchdog test to catch a service that is technically "running" but practically dead?
Write-up: https://blog.hoelee.com/posts/running-production-infrastructure-solo/
槽位 04. The Single-Writer Rule: Orchestrating AI Coding Agents Without Multi-Agent Chaos
- 系统标识 Key：
the-single-writer-rule-for-coding-agents - 所属分类：
case-studies - 博客源文章：https://blog.hoelee.com/posts/the-single-writer-rule-for-coding-agents/
- 排期规划：Wave 1 (立威期) | 拟发布时间:
2026-11-10 (Tue) - 顾问审阅结论：
通过（已微调）— 按顾问建议微调倒数第三段，用结构性消除 Git 锁竞争与合并前捕获 100% 幻觉回归，提升工程严密性。 - NocoDB 映射：Candidate Key
cand:the-single-writer-rule-for-coding-agents/ Draft Keycand:the-single-writer-rule-for-coding-agents:v1(status = APPROVED) - 正文字符数：2012 chars (符合 < 3,000 字符限制)
LinkedIn 拟发布动态最终修订稿：
When teams experiment with AI coding agents, the intuitive next move is almost always multi-agent parallelism: if one agent writes a feature in ten minutes, spawning four agents in parallel should ship the milestone in three.
In production, the exact opposite happens.
Unbounded multi-agent swarms writing to the same repository produce three immediate points of failure:
1. The Telephone Game: Orchestrators summarizing requirements to subagents introduce semantic loss at every layer.
2. Architectural Drift: Agent A builds a UI container using one state pattern; Agent B builds the underlying logic using another.
3. Git Collision Hell: Concurrent file patches create merge conflicts that LLMs resolve by silently dropping recently written code or entering infinite compiler repair loops.
The fix that works reliably: The Single-Writer Architecture.
I decouple agentic software development into three strictly segregated roles:
• The Exclusive Single Writer: The ONLY process with access to write tools (`patch`, `write_file`) and git staging. It maintains monotonic awareness of every mutation.
• Parallel Read-Only Workers: Specialized subagents running documentation indexing, schema validation, and test harness runs in parallel — strictly forbidden from touching repository files.
• Adversarial Reviewer: Once the Single Writer passes local unit tests, the raw `git diff` is handed to a fresh-context reviewer agent whose sole job is finding edge-case regressions, security oversights, and unnecessary token churn.
Across 5 full-stack tasks in a 50,000-line codebase, this architecture structurally eliminated git lock contention and caught 100% of hallucinated regressions prior to merge — without sacrificing parallel discovery speed.
Parallelize cognition and discovery, but strictly serialize mutations.
How is your engineering team preventing autonomous agents from stepping on each other in shared codebases?
Write-up: https://blog.hoelee.com/posts/the-single-writer-rule-for-coding-agents/
槽位 05. Architecting a 24/7 AI Support & Entitlement Engine Without Human-in-the-Loop
- 系统标识 Key：
how-i-built-the-digikedai-telegram-bot - 所属分类：
case-studies - 博客源文章：https://blog.hoelee.com/posts/how-i-built-the-digikedai-telegram-bot/
- 排期规划：Wave 2 (纵深期) | 拟发布时间:
2026-11-12 (Thu) - 顾问审阅结论：
需微调（已更新修订稿）— 求职红线防范：已按顾问修订稿消除电商副业色彩，强化 B2B 多租户权限开通与高可靠网关架构定位。 - NocoDB 映射：Candidate Key
cand:how-i-built-the-digikedai-telegram-bot/ Draft Keycand:how-i-built-the-digikedai-telegram-bot:v1(status = APPROVED) - 正文字符数：2101 chars (符合 < 3,000 字符限制)
LinkedIn 拟发布动态最终修订稿：
Deploying an LLM as a customer-facing bot is easy. Building an autonomous system that provisions production account entitlements without hallucinating or granting unauthorized access is an entirely different engineering challenge.
I architected a 24/7 support and automated trial-provisioning engine running across Telegram and WhatsApp. The stack: TypeScript + Node 20, grammY in webhook mode behind a Hono HTTP server, a self-hosted LiteLLM gateway, and PostgreSQL for persistent state.
Three architectural boundaries keep it reliable in production:
1. Three-Tier Retrieval Over Context Stuffing
Dumping an entire service catalog into system prompts guarantees hallucinated specifications and prompt injection risks. Instead, the engine resolves intent through a strict hierarchy:
• Deterministic plan/SKU regex token matching (`/\b[A-Z]{2,}\d{2,}\b/gi`)
• Normalized keyword metadata filtering
• Targeted semantic retrieval with bounded context injection
2. State Machines Over Prompt Engineering
An LLM is fantastic at natural language disambiguation and terrible at transactional state. Actions that mutate state — tenant trial provisioning, entitlement issuance, verification — run on deterministic TypeScript state machines. The LLM only parses intent; it never touches the business transaction directly.
3. The Webhook Timeout Trap
Telegram aggressively re-delivers webhook updates if your server does not respond within a tight window. If an LLM generation takes 4 seconds, Telegram re-fires the webhook, spawning duplicate model calls and cascading into an infinite reply storm. The fix: immediately acknowledge the incoming payload with HTTP 200, dispatch generation to an async worker queue, and enforce idempotency locks on the `update_id`.
The system runs autonomously in production, backed by ~175 unit tests verifying state transitions, retrieval precision, and payload contracts.
How do you separate deterministic business logic from probabilistic model output in your production agent workflows?
Write-up: https://blog.hoelee.com/posts/how-i-built-the-digikedai-telegram-bot/
槽位 06. Your Disk-Full Alert Is Lying: Stop Alerting on Percentages
- 系统标识 Key：
your-disk-full-alert-is-lying - 所属分类：
devops - 博客源文章：https://blog.hoelee.com/posts/your-disk-full-alert-is-lying/
- 排期规划：Wave 2 (纵深期) | 拟发布时间:
2026-11-17 (Tue) - 顾问审阅结论：
需微调（已更新修订稿）— 按顾问修订稿纠正第一人称复数 our -> my，统一 PromQL 指标为 avail_bytes，规范 PromQL 字节表达式。 - NocoDB 映射：Candidate Key
cand:your-disk-full-alert-is-lying/ Draft Keycand:your-disk-full-alert-is-lying:v1(status = APPROVED) - 正文字符数：1779 chars (符合 < 3,000 字符限制)
LinkedIn 拟发布动态最终修订稿：
I spent an afternoon deleting dozens of percentage-based monitoring thresholds from my Prometheus alerting rules.
Every single one of them was a ratio, and every single one was flawed in the exact same way.
Consider a standard threshold: alerting when free disk space drops below 10%.
On a 17 TB enterprise storage array, a 10% threshold fires a high-severity alert when there is still 1.7 TB of free space remaining. A routine nightly backup swings disk usage by 3%, triggering false pages while the host has hundreds of gigabytes of healthy runway.
Conversely, on a 50 GB system root volume, 10% means just 5 GB left. A runaway log stream or unrotated Docker container can consume 5 GB in ten minutes, crashing the host before an engineer even triages the notification.
A percentage ratio has zero concept of physical scale.
The rules I enforce for production observability today:
1. Alert on Absolute Headroom, Not Ratios: Replace `filesystem_used > 90%` with explicit byte boundaries (`node_filesystem_avail_bytes < 25 * 1024^3`).
2. Monitor Burn Rate: Use PromQL linear forecasting (`predict_linear(node_filesystem_avail_bytes[4h], 86400) < 0`) to detect rapid exhaustion rather than static watermarks.
3. Stop Misusing Memory Metrics: Alerting on `MemFree` is broken on Linux because the kernel actively utilizes unallocated RAM for page cache. The metric that accurately forecasts an OOM killer event is `MemAvailable`, not `MemFree`.
Alert fatigue is an operational vulnerability. If an alert does not dictate an immediate, unambiguous engineering action, it should not fire.
What is one legacy monitoring rule in your infrastructure that fires constantly without providing actionable signal?
Write-up: https://blog.hoelee.com/posts/your-disk-full-alert-is-lying/
槽位 07. The JPA @Version Field That Turns a Silent Lost Update Into an HTTP 409
- 系统标识 Key：
jpa-version-field-lost-update - 所属分类：
engineering - 博客源文章：https://blog.hoelee.com/posts/jpa-version-field-lost-update/
- 排期规划：Wave 2 (纵深期) | 拟发布时间:
2026-11-19 (Thu) - 顾问审阅结论：
需微调（已更新修订稿）— 职级拔高：补充 JPA 托管实体自动覆盖版本号的深坑解析，展现 Senior 级代码审查功底。 - NocoDB 映射：Candidate Key
cand:jpa-version-field-lost-update/ Draft Keycand:jpa-version-field-lost-update:v1(status = APPROVED) - 正文字符数：2248 chars (符合 < 3,000 字符限制)
LinkedIn 拟发布动态最终修订稿：
Two users open the same record in a web application. Both make changes. Both click save.
User A saves first; the database updates and the API returns HTTP 200. User B saves two seconds later; the database overwrites User A's changes, and the API returns HTTP 200 again.
User A's work has completely vanished. No exception was logged, no alert fired, and both clients were explicitly told their save succeeded.
This is the classic **lost update problem**, and it remains one of the quietest data corruption defects in read-modify-write REST APIs.
Here is how I enforce end-to-end optimistic locking in Spring Boot (Java 21) services — and avoid the subtle trap that breaks most implementations:
1. Add `@Version` to the Entity
Annotate an integer column with `@Version`. On every update, Hibernate automatically appends a version predicate to the SQL statement:
`UPDATE posts SET title=?, body=?, version=version+1 WHERE id=? AND version=?`
2. Enforce Version in the API Contract (and Avoid the Managed-Entity Trap)
Expose `version` in the read DTO and mandate it in the write payload (`UpdatePostRequest`).
The classic trap: if you call `findById(id)` inside your `@Transactional` update method and only copy mutable fields (`title`, `body`) onto that freshly loaded entity, Hibernate uses the database's current version rather than the client's stale version — silently bypassing optimistic locking. You must explicitly verify the client's submitted version against the loaded entity (or map the request version onto a detached state) before flushing.
3. Translate Concurrency Failures into Clean HTTP 409 Contracts
When concurrent requests race, Hibernate detects 0 rows updated and throws `OptimisticLockException` (wrapped by Spring as `ObjectOptimisticLockingFailureException`). A centralized `@RestControllerAdvice` translates this into an `HTTP 409 Conflict`:
`{ "error": "CONFLICT", "message": "Record was modified by another transaction. Please reload and reapply your changes." }`
An explicit HTTP 409 is infinitely better than a deceptive HTTP 200.
How does your backend architecture handle concurrent writes and state conflicts across distributed clients?
Write-up: https://blog.hoelee.com/posts/jpa-version-field-lost-update/
槽位 08. Stop Writing Agent Prompts for Deterministic Work
- 系统标识 Key：
stop-writing-agent-prompts-for-deterministic-work - 所属分类：
notes - 博客源文章：https://blog.hoelee.com/posts/stop-writing-agent-prompts-for-deterministic-work/
- 排期规划：Wave 2 (纵深期) | 拟发布时间:
2026-11-24 (Tue) - 顾问审阅结论：
需微调（已更新修订稿）— 防杠微调：交代最初挂在调度器背景与 125 行包含重试/去重/退避逻辑，立住工程克制力形象。 - NocoDB 映射：Candidate Key
cand:stop-writing-agent-prompts-for-deterministic-work/ Draft Keycand:stop-writing-agent-prompts-for-deterministic-work:v1(status = APPROVED) - 正文字符数：1959 chars (符合 < 3,000 字符限制)
LinkedIn 拟发布动态最终修订稿：
One of my automated background jobs failed 29 times in a row without sending an alert.
The core check was trivial: query npm for the latest published version of a CLI tool, compare it with the currently installed version, and send a notification if a newer version exists.
Two strings and a version inequality.
Because I already had an autonomous agent scheduler running daily ops summaries, I lazily wired this check as an agent prompt task instead of writing a dedicated script. Every cycle, an LLM parsed the CLI output and decided whether to alert. It worked fine until an upstream model routing change occurred. The agent framework recorded a model mismatch, triggered a silent drift skip, and exited cleanly without error.
The fix was not a more defensive prompt. It was deleting the LLM from the loop entirely.
The rule I enforce across all automated pipelines now:
**If the exit condition is a deterministic comparison — a string, a number, a status code — putting a model in that loop only adds failure modes.**
There is zero judgment required in `currentVersion < latestVersion`. Wrapping it in an LLM adds:
• Network latency and provider downtime
• Model drift and prompt deprecation risks
• Non-deterministic output formatting
• Unnecessary token billing
I replaced the agent task with a deterministic 125-line Python script handling HTTP retries, state deduplication, and explicit exit codes. It has run cleanly ever since.
Of the eleven automated operations loops I manage today, eight contain zero AI models in their execution path. The remaining three use LLMs exclusively where human ambiguity cannot be expressed as code: ranking unstructured emails, evaluating qualitative risk, and flagging stalled project contexts.
Where in your workflows are you using prompt engineering where a deterministic script would be infinitely more resilient?
Write-up: https://blog.hoelee.com/posts/stop-writing-agent-prompts-for-deterministic-work/
槽位 09. Why Dockerized API Notifications Silently Fail: An IPv6 and Framing Post-Mortem
- 系统标识 Key：
why-telegram-bot-notifications-die - 所属分类：
devops - 博客源文章：https://blog.hoelee.com/posts/why-telegram-bot-notifications-die/
- 排期规划：Wave 3 (收官期) | 拟发布时间:
2026-11-26 (Thu) - 顾问审阅结论：
需微调（已更新修订稿）— 补齐文末思辨提问；明确 extra_hosts 属于应急止血手段，展现专业网络协议排障能力。 - NocoDB 映射：Candidate Key
cand:why-telegram-bot-notifications-die/ Draft Keycand:why-telegram-bot-notifications-die:v1(status = APPROVED) - 正文字符数：2338 chars (符合 < 3,000 字符限制)
LinkedIn 拟发布动态最终修订稿：
An automated monitoring container in my production stack was scraping data flawlessly, but every Telegram alert suddenly began failing with:
`sendPhoto failed: 400 ... nginx/1.30.1`
It took a day of forensic debugging to uncover three independent networking and protocol failures masking each other:
Failure 1: Docker's Embedded DNS and IPv6 Blindness
Inside the container, `api.telegram.org` resolved exclusively to an IPv6 `AAAA` record (`2001:67c:4e8:f004::9`). The container was running on a standard Docker bridge network with no IPv6 routing, causing packets to drop across an unreachable interface.
Fix: Pin the IPv4 endpoint via `extra_hosts` in compose to immediately unblock routing, then enforce IPv4-only DNS resolution for non-IPv6 bridge networks.
Failure 2: The Telegram Edge Proxy Misdirection
Even after routing over IPv4, requests returned an HTML error: `400 Bad Request` with `Server: nginx/1.30.1`.
Because Telegram's API normally responds in JSON, I initially suspected an intermediary firewall or proxy intercept. In reality, `nginx/1.30.1` is Telegram's own ingress reverse proxy. When an HTTP request is structurally malformed at the transport layer, edge nginx rejects it before it ever reaches Telegram's application daemon.
Failure 3: Binary Multipart Boundary Corruption
The root culprit was an insidious line-delimiter bug in custom Python HTTP framing:
The payload was constructed by joining chunks with `b"\r\n".join(parts)`.
Because raw JPEG binary streams naturally contain `0x0A` (`\n`) and `0x0D` (`\r`) bytes, improper newline joining and framing calculations mutated the payload length and broke MIME boundary alignment, causing edge proxies to reject the HTTP stream on sight.
Fix: Concatenate discrete pre-framed multipart byte chunks verbatim with `b"".join(parts)`.
Hard-won debugging lessons:
• A Docker container on an IPv4 bridge network can still receive IPv6 `AAAA` records it cannot route.
• When a third-party API returns an unexpected HTML 400, inspect their ingress proxy layer before assuming an external network intercept.
• Never assemble binary multipart streams using string or newline helpers.
What is the most deceptive multi-layer network bug you have had to untangle in containerized production?
Write-up: https://blog.hoelee.com/posts/why-telegram-bot-notifications-die/
槽位 10. Architecting a Self-Healing Client Entitlement Engine with n8n and NocoDB
- 系统标识 Key：
self-healing-digital-goods-entitlements - 所属分类：
case-studies - 博客源文章：https://blog.hoelee.com/posts/self-healing-digital-goods-entitlements/
- 排期规划：Wave 3 (收官期) | 拟发布时间:
2026-12-01 (Tue) - 顾问审阅结论：
需微调（已更新修订稿）— 求职红线防范：脱敏数字商品电商词汇，全面升级为企业级多租户订阅与受控存储网关 IAM 授权架构。 - NocoDB 映射：Candidate Key
cand:self-healing-digital-goods-entitlements/ Draft Keycand:self-healing-digital-goods-entitlements:v1(status = APPROVED) - 正文字符数：2040 chars (符合 < 3,000 字符限制)
LinkedIn 拟发布动态最终修订稿：
In subscription and external client entitlement platforms, the hardest engineering challenge is rarely storage — it is **state reconciliation**.
Relying purely on one-off event triggers guarantees silent authorization drift in production:
• A subscription expires, but a dropped webhook leaves tenant access active indefinitely.
• A billing event fires during gateway maintenance, locking an active client out of provisioned resources.
To guarantee zero-drift authorization, I architected a self-healing entitlement engine using n8n workflows, NocoDB, and private storage gateways.
The core principle: **Access is never a static boolean flag; it is pure derived state.**
The system operates across five decoupled workflows:
1. Lifecycle Provisioning (W1): Listens for account state transitions, provisioning and toggling gateway identities deterministically.
2. Tier Permission Sync (W2): On confirmed subscription updates, computes the exact directory and resource paths matching the active tier and applies gateway ACLs.
3. Automated Expiry Sweeper (W3): A scheduled job running every 5 minutes evaluates timestamp boundaries and revokes expired path grants.
4. Continuous Reconciliation Loop (W4): Nightly at 03:00, a reconciliation engine computes the "desired authorization state" directly from the source-of-truth database and audits it against the live storage gateway. Any drift is automatically repaired and logged to telemetry.
5. Zero-Leak Entitlement Verification (W5): Client-facing portals verify active entitlement status via scoped read-only token queries without exposing underlying database credentials.
By modeling permissions as a continuous reconciliation loop (similar to Kubernetes controllers), transient network drops or webhook timeouts self-heal on the next cycle without human intervention.
Do your authorization workflows rely on brittle one-off webhooks, or do you run continuous reconciliation loops to catch state drift?
Write-up: https://blog.hoelee.com/posts/self-healing-digital-goods-entitlements/