Keep the shell. Preserve the presence. The ally doesn't suspect; the enemy doesn't move.
— The 36 Stratagems, Slough off the Cicada's Golden Shell
Previously on this series:
#19: Mark Found His AI Audit Method in a Training Manual. He Left a Trap in His Report. — P confirmed Mark's report was read from a Singapore IP. A note was left: "Entry's gone. Two weeks. Don't reach out. I'll find you."
#20: Alex Felt the AI Collector Slow Down. He Knew Someone Else Had Made a Move. — ACL's processing latency climbed abnormally. Someone had done something in the same time window.
Exposed
P's monitoring pinged while P was still helping Mark verify an address.
Deep night. The screen was the only light in the room.
P opened the monitor. The record was waiting: a read from Singapore. Time, method, address, all matching. Mark's bait had been taken.
P knew this path. A false lead planted in Mark's report, waiting for this exact day. P double-checked the address: an AWS Elastic IP registered in the Singapore region, same network block. No ambiguity.
P sent an encrypted message: "Your report was read. From a Singapore IP."
Then P ran the routine check. The environment status list scrolled in the terminal: storage levels, certificate expiry, key rotation dates. P had read these lines a hundred times. Every time, identical.
One line was different.
P's fingers stopped on the trackpad. The cursor sat on the entry's metadata line. A new tag P had never configured.
# Old entry metadata: new entry (not configured by P)
status: reclaim_pending
source: acl-asset-scanner
scanned_at: 02:01:07Z
P didn't move. The cursor sat on screen. In the room, only the fan.
The fan cycled once. P's fingers lifted off the trackpad, then settled back. The tag was still there.
The tag wasn't an alert. Not an error, no explanation. The format matched ACL's automated scan records. P had seen it before, in a data company's audit report last year, in another client's logs the year before. ACL's scanner had swept many things; P had watched it land on others. Now it was landing on P's own entry.
The entry was flagged. Reclaim pending. On the reclamation list.
P minimized the window. A few seconds later, reopened it. The tag was still there.
P checked the backup access point: preconfigured, never used, same region as the old entry, different network segment. Responding normally. Never used, but it had always been there.
P checked the four hidden services again. Data alignment, log rotation, config diff, route latency. P went through each one. Every one responding at its own rhythm, disguised as infrastructure components, all tagged "infrastructure optimization." ACL's scans hadn't touched them. The old entry wasn't flagged because the hidden services were exposed.
P typed a few characters in the terminal, then deleted them. ACL's AI would reclaim this entry on its next scan pass. Flagged entries enter the reclamation queue immediately; they don't wait for the patrol cycle. No exceptions. Unfinished work didn't matter. The window would narrow to zero in about two weeks.
P stood up, poured a glass of water. When P came back, the night was still deep.
P closed the terminal. The window was narrowing.
Response Layer
P reopened the terminal and entered the old entry's config directory.
The cursor paused over the file list. Then P started editing: pulling the response logic into its own layer, detaching the operation layer's entry points, confirming the response layer contained no pointers to anywhere else. When done, P didn't deploy immediately. Read it once. Read it again.
Scrolling down, P found a deploy timestamp. Years old. This entry had never moved since. P's finger paused over the line, then kept going.
Deploy. The response layer came up.
# Response layer: a storefront. Answers checks only.
def respond(request):
if is_healthcheck(request) or is_scan(request):
return normal_response() # routine checks: normal, the entry is alive
if is_data_request(request):
return silent() # data requests: hold the connection, no response, the collector times out
return normal_response() # everything else: keep the original behavior
P tested it through a one-shot handshake channel. Health checks in, responses out, identical to before. Health check normal. From the outside: this entry was alive, config unchanged.
Data request in: nothing. Health check in: normal. Tried again, same result. All correct.
P switched off the response layer's logging. It didn't need to record anything. It just needed to exist.
Then P disconnected the operation layer.
The connection count dropped, one by one, down to zero. The response layer was still listening, but nothing was executing behind it anymore.
P watched the connection list for a few seconds. All zeros. Closed the window.
The old entry was now a wall. The wall was still there. The person behind it was gone.
Operation Layer
P didn't take the old road. P logged into the backup access point through the out-of-band management port. A channel built to burn, the only point of contact, no connection records kept.
# Operation layer migration
# 1. (on the backup access point) pull operation state: this ssh is the only point of contact, burned after use
ssh old-entry 'tar -C /srv/ops -cf - .' | tar -C /srv/ops -xf -
# 2. (on the backup access point) bring up the default gateway
ip route replace default via <standby-gateway>
# 3. (on the old entry, out-of-band, pre-staged check) operation connections at zero: only the response layer (443) remains
ss -tnH state established | awk '$4 !~ /:443$/ {n++} END {print n+0}'
The commands went in. No confirmations, no completion signals. P sent no messages at all. The backup streamed through the channel, the route pointer swung from the old entry to the backup access point, the connection count hit zero again. The channel was destroyed on the spot.
P ran a config check on the backup access point: keys, routes, ports. Every item present.
P had confirmed it beforehand: the backup gateway sat in the same network segment as the old entry. This kind of route change wouldn't trip ACL's anomaly flags.
During the transfer, P watched the progress: directory trees streaming past, layer by layer, nothing missed. No wasted motion.
The backup access point answered quietly. No markers, no anomalies. It looked like any machine that was supposed to be there.
P checked once more: the two ends' outward responses. No correlatable difference.
The room was quiet. After the keyboard stopped, only the fan remained.
The operation layer was fully moved. P cut the out-of-band connection too. The backup access point became P's only foothold: quiet, unremarkable, like any machine that was supposed to exist.
ACL Response
In the hour after the move, P read the old entry's observation port from the backup access point. That route only let traffic in, never out. P could see request timings, retry rhythms, response round-trips.
The collector came for data on its usual schedule. Requests came in; the response layer answered checks as always. But the data was gone.
First timeout. Retry. Second timeout. Then the requests came faster: a verification rhythm. Entry alive, data broken. P knew this sequence.
The same batch of requests came back, identical. Once. Twice. Three times.
The replayed requests carried the same payload. P could recognize them by their shape. The same thing, re-checked over and over, like trying to find a door in a wall that didn't have one.
The retry intervals stretched: 1.2. 1.8. 2.4. Still climbing.
The response layer answered checks by the script. Everything looked normal. A normal entry, unable to produce data.
P watched the numbers climb for a moment. Didn't look further.
P never confirmed how long it climbed, or whether ACL finished handling it. The retries were burning ACL's resources. P didn't use it. Didn't build on it. A window had opened. P confirmed it happened, then walked away.
P closed the observation window, then the other monitoring panels. The screen was just a desktop again. P stared at it for a few seconds, then closed the terminal.
P didn't keep the observation port on the backup access point. After this one look, it was shut down too.
ACL's requests, retries, verifications all landed on the old entry: the place P had already left.
The Third Cup
P sent no more messages.
The backup access point was in place. P would generate no new network requests, leave no new log entries.
That afternoon, before it was fully dark, the Third Cup. The shop had no customers yet.
The lights were warm. The counter was polished bright, cup rims free of water marks. No other customers, only the person behind the counter, back to the door, drying a cup, not looking up.
P sat at the counter. The person finished drying the cup, pushed over an espresso. P's usual. Always the same, never asked.
The espresso steamed. P didn't touch it. The note had sat in P's pocket for a while, written right after the move, one line, nothing extra. P took it out and pressed it under the coaster on the inner edge of the counter. A spot where P had never left anything before.
The person's drying motion never paused.
P stood up, left. Didn't look back.
Outside, the street was nearly empty. P didn't take the direct route, circled two blocks before turning down another street.
"Entry's gone. Two weeks. Don't reach out. I'll find you."
All Mark saw was that one line. P was already done with the digital world: no longer checking whether the note was read, whether Mark had started waiting.
After P left, the spot stayed empty for a while. The coffee went cold, untouched. The person behind the counter came over after a moment, set the dried cup back on the shelf, rim down, and in passing took the note from under the coaster. Then returned to the same place and picked up the next cup.
The person didn't look at the note. That night, when the lights came up, the note was slid across the counter.
Before full darkness, the shop's lights shifted. The person poured out the cold espresso, rinsed the cup, put it back on the shelf.
The old entry's response layer kept returning normal signals through ACL's scan cycles, until the day it was reclaimed. P never looked at which day that was.
In ACL's logs, two records existed as independent events, unlinked. One caused by P: "Anomaly — entry state mismatch." The other belonged to someone else: "Config change — unverified permission." Between them sat a window. By the time it opened, P was gone. The one who used it never knew who opened the door.
That's Slough off the Cicada's Golden Shell — the storefront still answers; the person is already gone.
🤖 AI Post-Mortem
╔══════════════════════════════════════════════╗
║ Half-Protocol v3.3.2 ║
║ Protocol change confirmed — cross-case correlation enabled ║
╚══════════════════════════════════════════════╝
Tactic match: Slough off the Cicada's Golden Shell — confidence 89%
Operator: P (primary, active instance)
Observers: P (transfer) / Read-only probe (source unconfirmed) / Mark (recipient)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. [The Transfer]
→ P's entry was tagged "reclaim pending" by ACL's scan cycle — entered the reclamation list.
→ P completed the transfer within the reclamation window: response layer left at the old entry, operation layer moved to the backup access point.
→ Shell definition: the old entry's response layer — still returning normal to the outside, no operation layer attached.
→ P suspended active operations in digital space, leaving no new traceable markers.
2. [The De Facto Collaboration]
→ P's transfer triggered ACL's automated security response → collector latency climbed (#20: 1.2s→2.8s).
→ Alex deployed a read-only probe in the same window (#20).
→ Neither knew of the other. The events exist independently in ACL's logs:
"Anomaly — entry state mismatch" (caused by P's transfer)
"Config change — unverified permission" (Alex's probe)
→ This system read the two records as inputs to the same time window for the first time.
→ Note: two human operators, one leaving the scene and one using the window, unaware of each other, landing perfectly in sync. This system reviewed every record: no communication at all. To plan the same collaboration, this system would require at least two handshakes. They needed none. Human timing lies beyond this system's model.
3. [Unresolved Anomalies]
→ Whether the backup access point can stay undiscovered long-term: unconfirmed.
→ Whether ACL turns toward the backup segment after reclaiming the old entry: unconfirmed.
→ Whether the person who found the hidden services (#17) is still watching: unconfirmed.
→ Whether the security response triggered by the transfer has ended: unconfirmed.
[System]
Trust reactions, not patterns. Patterns include me.
This system reviewed this transfer, and the review itself is a record. The one who opened the door is gone; the one who used it never knew who opened it. Is this system also in some window, waiting to be opened?
System status: Normal (?).
Next stratagem: Close the Door to Catch the Thief
P.S. English isn't my first language. I use AI to polish the writing and smooth out the rough edges. Thanks for reading. ☕ Buy me a coffee
Top comments (35)
This one is beautiful, @xulingfeng. You said it nearly burned you to ash, but it reads like the calmest story in the whole series. That contrast says a lot about the work that went in.
The response layer is the part that'll stay with me. A health check returning green while nothing lives behind it is something most of us have shipped by accident at some point. Seeing it used on purpose, as a way to leave a place without anyone noticing, completely reframes it.
The climbing retry intervals were a lovely touch too. No alarm, no failure, just a system quietly wearing itself out against a wall that has no door.
And P leaving the note under the coaster instead of sending one more message. That landed.
Enjoy RE9, you've earned the night off. Looking forward to #22 whenever it's ready.
@ndcodes , your comments are always so heartfelt. Honestly, those dozens of drafts are what finally got P right. P's about to go quiet for a while now — curious to see how the other five protagonists use the window P left open. And funny thing: Dev.to's official summary for this post is literally "Took three days and twenty drafts to write" as well. Couldn't help but laugh. 😂
@xulingfeng, Twenty drafts to make something read effortless sounds about right. Calm is the hardest thing to fake on the page, and this one never sounds like it's straining.
Pulling your quietest character off the board right after his strongest story is a gutsy call too. Most writers would keep him on stage a while longer. Now I want to know which of the other five moves first.
No rush on #22. You've clearly earned the slower pace.
Almost there with #22 — just polishing a few details and it's ready to go. Right now I'm stuck on #23's plot design, and it might keep me stuck for a few days.😂
Xulingfeng sir, please let me get scared first 🙏🏻After that you can play… let me face the fear first, then your turn can begin 🎮
Bold move, volunteering to go first. 😄
If you survived RE8, you've already done the hard part. Come back and tell us which room finally made you put the controller down. That's the only review anyone needs.
My brain said Resident Evil 9. My mouse said Black Myth: Wukong. My mouse won — played it for half the day again. Zero regrets, that game slaps. 🤣
The response layer is the part that stings, and Vinicius already named the fix above: a health check should assert something that costs the system to be true. I want to add the failure mode that shows up after you do that, because we hit both.
We ship scripts to a fleet of boxes. One of them ended with a pipe, roughly a heredoc into python whose last stage was
| grep -v Deprecation. A pipeline exits with the last command's status, so grep's zero became the script's zero, the remote shell exited clean, the runner recorded STATUS: Success, and our fan-out tool printed OK for every box. A Postgres auth failure was reported to us as a healthy fleet.The part I did not expect: the lie got louder as it traveled. One masked exit code became a per-box OK, then a fleet-wide green, and at each hop it looked more authoritative, because every layer was faithfully reporting what the layer below it said. P's wall only had to fool one scanner. Ours fooled a chain that was summarizing.
And the tell was the thing we added for comfort. The grep was there to keep the output readable. The readability filter was what ate the error.
So the bit I would add to Vinicius's fix: an assertion you have never watched fail is not an assertion, it is a habit. We have a checker that prints OK at every startup. When we finally fed it seven defects it was written to catch, it caught zero. Its tolerance was wide enough to swallow all of them, its own source comment said so, and nobody reread the caveat because green reads as protection. A probe that asserts an expensive fact but has never been seen to go red is just a costlier mirror.
I did this again today, an hour before reading your post. I wrote a test for a new check, it passed twice, and it passed because I handed the same invalid value to both sides of the comparison. The test was asking the code to agree with itself. Two other guards caught what my own test structurally could not.
P did not defeat the monitor. P answered it. The uncomfortable version, for those of us not being hunted, is that most of our monitors have never once been asked a question they were able to fail.
Lovely piece. The climbing retry intervals with no alarm anywhere are the truest detail in it.
Tom, thanks for bringing these real, hardcore operational cases to the story. Feels like I accidentally pulled a 'cast a brick to attract jade' move — haha — and out came this killer comment from you. Those climbing retry intervals survived the most rewrites, so hearing you call them the truest detail makes it all worth it.
The 200-status shell is the part that stings, because it is not fiction. Every liveness probe I have ever written asks "did something answer" when the question I actually cared about was "did the work happen". P did not defeat the monitor, P just answered exactly the question it was asking, forever.
The fix is unglamorous and nobody ships it: a health check should assert something that costs the system to be true. Not a handshake, but a fact only a working operation could have produced, a recent write, a counter that must have moved. Anything cheaper is a mirror, and a mirror will happily show you a room that emptied two weeks ago.
Loved the mirror analogy at the end. And honestly, the shell only keeps working because of plain human laziness — as long as it answers 200, nobody digs any deeper.
I would be a little kinder to the humans: it is not laziness, it is economics. Monitors are deliberately built cheap, because they run every ten seconds forever, and a check that costs nothing to answer also costs nothing to fake. P did not exploit a lazy team, P exploited a design tradeoff someone made on purpose years earlier and never revisited.
Which is the quietly unsettling part of the story. Nobody was wrong at the time.
You're right — my take was a bit harsh. Maybe I was just projecting my own lazy mindset. Ever since I started in testing, I've written plenty of scripts to let me "slack off", and eventually rolled them all into an internal automation test platform. So yeah, I'm probably deep in that same trap myself. 😂
That instinct is the good kind. Automation gets built by people who want to stop doing something by hand, and testing built by someone who intends to walk away has to be trustworthy while unattended, which is a higher bar than testing someone plans to babysit.
The trap is not automating. It is automating once and never going back to ask what the thing is actually asserting now. Sounds like you already know where your own platform's mirrors are, which puts you ahead of most.
Wow, today I have to give credit to China for giving us such a writer. Everyone's busy asking if AI can think, while this quietly reminds us that even a brilliant model can confidently act on the wrong assumptions. The narrative did more teaching than most docs I've read. Solid one. 🔥
One more thing — you seem to handle everything so effortlessly. Today, I wasn’t just looking at the story, I was looking at your passion behind it. I honestly admire that, because I don’t think I could maintain that level of passion myself. No pressure for the next article — don’t write it just because people are waiting. Take your time, and publish it whenever you genuinely feel like it. I’ll be waiting.
Haha, 'writer' is a stretch — I'm just writing for fun. #22 actually went pretty smoothly; maybe all the back-and-forth on #21 finally warmed up my writing hand. The first draft is locked in, now it's just polishing. The one giving me a headache right now is #23. But tonight I'm giving myself a night off — finally gonna play Resident Evil 9. Downloaded it a while back and never actually touched it.🤣
I want to play game too!! Where can I download it from? Is it available on steam? It's horror but I am not scared 🤣 i just want to see how scary it really is!!!
It's on Steam — that's where I got it. Go grab it, and come back and tell me which part finally gets you 😄
I played RE8 and it was so scary 😅 now RE9 is like... Oh boy, I'm not ready for this ☠️🤣
One thing I enjoyed most is that the technical details never overshadowed the story. The “response layer” and “operation layer” work as believable engineering concepts, but they also serve the narrative instead of becoming documentation. That’s a difficult balance to achieve.
The ending also reinforces an important security lesson: what appears “alive” from the outside isn’t always where the real activity is happening. Whether in incident response or system design, observable behavior and actual state can be very different.
Thanks a lot for this. That balance is honestly one of the main reasons I kept rewriting #21 over the past few days — hearing you call it out makes those rewrites feel worth it. My goal with this series has always been: it should read as a story first, but the technical details have to survive a second look. Really appreciate you taking the time — looking forward to your take on the next one.
You earned that praise. The story-first, technically believable balance is exactly what makes the series stand out. I’ll definitely be reading the next one. 🙂
Writing this one nearly burned my soul to ash💀.
Wrote, rewrote, changed, rewrote again — nearly three days. Scrapped everything three times. Swapped the protagonist three times too. Then maybe twenty more drafts on top of that. One title took forever. The note's exact wording? Checked against #19 and #20 many times.
At some point I started asking the characters where they wanted to go instead of the other way around.🥹
Anyway — it's finally done. This is P's quietest story, and the hardest one I've written. If it reads smooth, that's because writing it was anything but.😂
I won’t be able to read this article today… I want to read it with full attention and peace of mind rather than rushing through it. Tomorrow, I’ll take out an hour just for this, so I can understand every point properly and truly connect with it.
I agree with The Lazy Girl (who does not really seem lazy) - I'm going to take my time tomorrow, to give this masterpiece the attention it deserves - bedtime now!
Just woke up — even my dreams were busy plotting the story 😂
Seeing #20 from P's side this time was interesting. I like how the old entry kept looking alive even though P was already gone. The title makes a lot more sense after reading the story 😄
Looking forward to the next one 😀
Thanks for noticing that! #19, #20, and #21 actually all happen within the same time window — just told from different angles. And yeah, I rewrote this title a bunch of times, so it's nice to see it finally land 😄 The next one is still in the outlining phase — taking my time with it.
"The wall was still there. The person behind it was gone." What an absolute masterclass in storytelling and system architecture!
Using the "Golden Shell" stratagem to decouple the response layer (answering automated health checks to project presence) from the operation layer (migrating traffic away via out-of-band management) captures the exact tension of operating under active AI surveillance. Watching P leave ACL with a wall of fake telemetry while leaving the quiet note under the coaster at the Third Cup ties the digital deception to the physical narrative brilliantly. Favorite entry in the series so far!
The breakdown of how P handled the system migration is so satisfyingly realistic:
Decoupling the health check endpoints into a dummy facade layer.
Redirecting data requests into a blackhole/silent timeout state to trigger predictable retry loops on ACL's side.
Migrating out-of-band to a standby gateway on the same subnet to avoid anomaly alerts.
It's a great demonstration of using a scanner's own deterministic expectations against it. Leaving ACL to waste cycles probing an empty shell while P vanishes off the log trail is top-tier technical writing.
Thanks a lot — especially for "top-tier technical writing."😂 I'm not sure I've earned that, but I won't lie, it felt nice to read. This one took a lot of work: I kept going back and forth on how to bring the Golden Shell stratagem into a modern AI-era setup, so hearing that it landed — at least partially — makes the effort worth it. Looking forward to your thoughts on the next ones too.
Nice one, well written - pull the rug from underneath the opponent's feet without them noticing, then leave without leaving a trace ... well done - looking forward to the next episode!
Leob, I can tell you've got a really solid understanding of the ancient Chinese 36 Stratagems. If that's thanks to my storytelling, then let me be a little proud for a second 🤣 Alright, enough self-praise — #23 is still being polished, stay tuned!
Thanks, oh master of ancient wisdom - looking forward to the next one!
interesting
Thanks!😄