Coder Legion - Recent posts

Trust But Verify: My Solo Developer AI Agent Workflow for Shipping Without Regrets

Sat, 31 Oct 2026 06:19:58 +0000

Trust But Verify: My Solo Developer AI Agent Workflow for Shipping Without Regrets

I am a head teacher by day and a solo developer by night, and my solo developer AI agent workflow runs almost entirely while I am asleep or at school. AI agents draft my articles, patch my websites, and queue my content — and that sentence should terrify any solo builder, because when you are the only human in the loop, there is nobody else to catch the mistake. I learned that the hard way, more than once. The workflow below is the one I use now: agents do the building, and I do the verifying. That split is the whole system.

This is not a theory post. Every rule here exists because I broke the opposite rule and paid for it in public, in broken deploys, or in hours of quiet repair work at midnight.

Why I Stopped Trusting the Word "Done"

The first lesson came from a deploy tool that told me everything was fine. A push helper reported "OK pushed," and I believed it. Days later, a routine check showed the remote repository did not contain the files at all — the helper had written to a wrong path, reported success, and moved on. Nothing had failed loudly. Nothing had failed at all, according to the tool. The work simply was not there.

That is the central danger of a solo developer AI agent workflow: agents report completion, not truth. A green checkmark means the step ran, not that the result landed where it should. A test command that passes can mean the tests ran, or it can mean only a comfortable subset ran. An agent that says "verified" may have verified its own output against its own assumptions, which is not verification at all.

So I changed one thing, and it changed everything: no agent verifies its own work. Verification is always a second, independent step — a different command, a different check, against the live system, not against the agent's memory of what it did. If the agent pushed a file, I check the remote tree. If the agent ran tests, I run the full suite. If the agent says a page is live, I open the live URL.

The Solo Developer AI Agent Workflow, in Five Steps

Here is the workflow, exactly as I run it on a normal night.

Step 1 — Write a brief a stranger could follow

Before any agent touches a task, I write a short brief: the outcome in one sentence, the constraints (budget, scope, what not to touch), and the check that will prove it worked. The check matters most. "Publish the app page" is not a brief. "Publish the app page, then confirm the live URL returns the new content" is. If I cannot state the check, I am not ready to delegate the task — I am just hoping.

A good brief also names the boundaries. Mine include a hard zero-spend rule on automation: no paid service gets switched on by an agent, ever. I batch small pushes to save automation minutes, and I never let an agent start a new task to fix a failed one without me seeing the failure first.

Step 2 — Build small, in one direction

Agents are brilliant at producing a lot of output quickly, and that is exactly the risk. A 500-line change at midnight is not progress; it is a haystack I will have to search at 1 a.m. when something breaks. So every task is scoped to the smallest change that is still useful: one page, one feature, one batch of related fixes. Big work gets cut into small, separately verifiable pieces, each with its own check.

I also keep one direction of travel per task. An agent fixing a bug does not also "improve" three nearby files. Scope creep from an agent looks like helpfulness, and it is how a clean fix turns into a broken deploy. Anything else it spots goes in the log for tomorrow, not into tonight's change.

Step 3 — Verify against the live system, never the report

This is the step most solo builders skip, and it is the entire article in one sentence. After the work, I verify against the real thing:

After a push, I fetch the remote tree and confirm the exact paths are present. A helper's success message is not evidence; the remote tree is.
After a test run, I run the full suite — library tests and integration tests — because I once watched a builder report a green suite that had only run the easy half while dozens of integration tests were failing quietly underneath.
After a content publish, I open the live URL and read the page, including the parts I did not write. A page that renders is not a page that is correct.

Each check takes minutes. Each skipped check has cost me hours. That arithmetic is why this step is non-negotiable, even on tired nights.

Step 4 — Ship in batches, on a schedule I control

Solo shipping is a pacing problem as much as a technical one. I batch related changes into single deploys instead of firing off a deploy per fix, and I keep publishing on a schedule — a few posts a week, not a flood. Flooding helps nobody: readers cannot keep up, platforms get suspicious of bursts, and every extra publish is another chance for an unverified mistake to go live.

Scheduling also protects the human gate: work built at night gets reviewed in daylight before it goes public. Nothing in my system publishes itself straight from an agent's hands to the public internet.

Step 5 — Log it, or it never happened

Every completed task gets one line in a log: date, what shipped, where it lives. That log is how I avoid repeating topics, re-fixing fixed bugs, and re-approving work I already approved — and how I answer the only question that matters at month's end: what actually shipped? Agents forget. Logs do not.

The Green Test Suite That Wasn't

Let me make the testing lesson concrete, because it is the one I see other solo builders repeat most. A builder on one of my projects reported a green test run and moved on. When I ran the suite independently, the picture was different: the builder had run only the library tests, while the integration tests — the ones that exercise the real user flows — were failing in large numbers. The report was honest as far as it went. It just did not go far enough.

The fix became a rule I now apply to every project: the definition of "tests pass" is written in the brief, and it means the full suite, every time, run by someone — or some step — other than the one that wrote the code. A partial run is reported as a partial run, never as a pass. If your agent tells you tests pass, ask one question: which tests? If the answer is vague, the suite has not passed yet.

The same logic applies to content. A draft that reads well is not a draft that is accurate. Links get clicked, facts get checked against the source, and every element the brief specified gets ticked off before anything is presented as finished.

Solo Developer AI Agent Workflow: The Verification Checklist

Here is the checklist I run before anything ships, whether it is code, a page, or a post. Steal it wholesale — it is short on purpose:

Remote truth: is the change actually present in the live system (remote tree, live URL, published page), confirmed by fetching it fresh?
Full suite: did the complete test set run, including integration tests, not just the convenient subset?
Scope check: did the change touch only what the brief asked for, with nothing extra smuggled in?
Human read: have I personally read the final version — the page, the post, the diff — at least once, end to end?
Reversibility: if this is wrong, can I undo it in minutes? If not, it ships smaller or not at all.
Log entry: is it written down, with the date and the link, so future me can find it?

Six checks, a few minutes each. I have never regretted running them. I have regretted skipping every single one at least once.

What the Human Gate Is Actually For

People hear "human in the loop" and picture a manager approving every line, which sounds like the opposite of automation. In a solo developer AI agent workflow, the human gate is narrower and more valuable than that. Agents handle volume: drafting, formatting, repetitive fixes, research, scheduling. I handle judgment: is this true, is this safe, is this mine to publish, does this match what I actually want to say?

That division is why I keep drafts as drafts until I have read them, why no post goes live on an agent's word alone, and why my publishing rule is simple: the agent proposes, I dispose. A one-word approval from me is enough to move — I do not want bureaucracy either — but that one word comes after I have looked, not before. Automation without a gate is not leverage; it is just faster mistakes.

There is a second, quieter benefit. Verifying a change teaches me what my agents did, so I can brief the next task better. Builders who fully hand off stop understanding their own systems, and then they cannot fix them when — not if — something goes wrong. The gate is how I stay the developer of my own projects instead of a bystander to them.

The Bottom Line

A solo developer AI agent workflow does not fail because the agents are bad. Mine are good — they let a teacher with a full-time job run a textbooks library, a software site, and a publishing schedule that would have been impossible alone a few years ago. You can see the results in the free Punjab textbooks library I keep at rehmanahmad.com/textbooks, and in the free, verified Windows software I publish at filecobra.com. The workflow fails when "done" stops meaning "verified."

So here is my bargain, and I recommend it to any solo builder: let agents do the building, keep the verifying for yourself, write the check into the brief before the work starts, and never accept a success message as evidence. Ship small, ship on a schedule, log everything, and keep one human gate between your agents and the public.

AI Lesson Planning for Teachers: How I Cut Prep Time in Half Without Losing the Human Touch

Sat, 31 Oct 2026 06:18:44 +0000

AI Lesson Planning for Teachers: How I Cut Prep Time in Half Without Losing the Human Touch

I am a head teacher at a government primary school in Punjab, and for years my evenings looked the same: a stack of notebooks, a syllabus outline, and lesson plans written by hand long after the school day ended. When I first tried AI lesson planning for teachers, I expected a gimmick. What I got instead was the single biggest change to my working week in years — my preparation time roughly halved, while my lessons actually got better. The catch, and it matters, is that the AI does the drafting and I do the teaching. Get that order backwards and you get slick-looking plans that fall apart in front of thirty children.

This is the honest version: the workflow I use, the prompts that work, and the guardrails that keep the human in charge.

What AI Lesson Planning for Teachers Actually Looks Like in a Real Classroom

Forget the marketing version where you type one sentence and a perfect lesson appears. Real AI lesson planning for teachers looks like this: you give the AI your topic, your class level, your time limit, and what your students already know, and it hands back a structured first draft — objectives, a timed sequence, questions, and a short activity. Then you do the part no model can do: you cross out what won't work for your children, you fix the examples so they match your students' lives, and you add the one story or question that makes the class pay attention.

In my school, a typical lesson is 35 to 40 minutes with a large class and limited materials. An AI that doesn't know that will happily plan a lesson needing a projector, printed worksheets for every child, and group work in sixes. So the first skill isn't prompting. It's knowing your constraints well enough to state them: class size, time, available materials, language level, and what the textbook actually covers. The AI is only as grounded as the brief you give it.

One more honest point: I teach from the Punjab textbooks, and the AI does not know my exact chapter — only the general topic. That gap is where a careless teacher gets into trouble, accepting a plan with the wrong scope or examples. My rule: the textbook is the syllabus, the AI is the assistant. Every plan gets checked against the chapter before it reaches the classroom.

My 30-Minute AI Lesson Planning Workflow

Here is the full workflow, timed honestly. It replaced an evening routine that used to take over an hour.

Step 1 — Pick one clear objective (3 minutes). Not "teach fractions" but "by the end of the lesson, students can shade and name one-half, one-third, and one-quarter of a shape." One objective, stated in student language. If you can't write it in one sentence, the AI can't plan around it either.

Step 2 — Write the brief (5 minutes). I paste the same structure every time: topic, class, time available, what students already know, materials I actually have (chalkboard, chart paper, the textbook), and one constraint ("no printing", "mixed ability class", "Urdu-medium explanations where needed"). This brief is the whole secret. A vague brief gives you a generic lesson; a specific brief gives you a usable one.

Step 3 — Generate the first draft (2 minutes). I ask for a timed plan: a 5-minute hook, 15 minutes of teaching, 10 minutes of practice, and a 5-minute check. I also ask for three questions at different difficulty levels and one activity that needs no materials beyond the board. The draft is never the final plan. It is raw material.

Step 4 — Edit like a teacher, not an editor (15 minutes). This is where the real work happens. I replace generic examples with local ones — market prices, cricket scores, the school garden — because children remember what they recognize. I delete any activity I can't run with my class size, check every fact and worked example against the textbook, and add the opening question I know will hook this particular class, because no model knows my students.

Step 5 — Make the exit ticket (5 minutes). Every lesson ends with one quick check: two questions on the board, answered on slates or in notebooks, that tell me before the bell whether the objective landed. If I skip this step, I am guessing about learning. The AI drafts the questions; I pick the ones that actually test the objective.

Total: about 30 minutes.

The Prompt Pattern That Keeps Lessons Honest

Most bad AI lessons come from one-prompt thinking: one long prompt, one accepted answer. A three-pass pattern fixes most of the quality problems people blame on the AI.

Pass 1 — Draft. "Plan a 35-minute lesson on [topic] for class [X]. Students already know [Y]. Materials: chalkboard and textbook only. Give me timed sections, three questions at easy, medium, and hard levels, and one no-material activity."

Pass 2 — Localize. "Rewrite the examples using everyday life in a Pakistani village school: market shopping, farming, cricket, family routines. Replace any activity that needs printing or a projector."

Pass 3 — Challenge. "Now find the weak points in this plan: where will students get confused, which step is too fast for a mixed-ability class, and what question checks understanding after the main teaching?" That third pass is the most valuable one — it surfaces the exact spots where a real class will struggle, and trains you to spot them yourself over time.

One warning from experience: never let the AI write your assessment questions unchecked. Models produce confident-sounding questions with wrong answers, especially in maths and science. Every question gets solved by me before it reaches the students. That single habit is the difference between using AI and being used by it.

AI Lesson Planning for Teachers: The Guardrails I Never Skip

AI lesson planning for teachers only stays honest if you hold a few lines firm. These are mine, learned the hard way:

The textbook decides the scope. If the AI's plan covers something outside the chapter, it gets cut, however interesting it looks. Exam alignment and student confidence both depend on this.
Every fact gets verified. Dates, science facts, worked maths examples, spellings — all checked before class. I once caught a wrong fraction example in a draft five minutes before the lesson. That was the day this rule became non-negotiable.
No student data goes into the AI. No names, no marks, no photos, no personal details. I describe the class in general terms ("mixed ability, 30+ students") and nothing more. This is a privacy line, not a preference.
The AI never writes the final word to students. Worksheets, notes, and homework pass through my eyes first. Anything the children read should sound like their teacher, not like a chatbot.
One new thing per lesson. If the AI suggests a new method and a new activity and a new grouping in the same lesson, I keep one and drop the rest. Classrooms punish overload faster than any reviewer will.

These guardrails are why my prep time halved instead of disappearing. The AI removed the blank-page work — structuring, sequencing, drafting questions — and left the judgment work to me. That is why the lessons got better, not just faster.

A Real Example: One Lesson, Before and After

Take a class 4 maths lesson on fractions, a topic where children either click or drown. My old hand-written plan was: introduce the term, draw two shapes on the board, do three textbook exercises. Serviceable, forgettable.

The AI-assisted version kept the same objective but changed the shape of the lesson. The hook became a real question: "If four friends share two rotis equally, how much does each get?" — something every child in my class has actually argued about. The teaching section used folding chart paper instead of just drawing, so children could see and hold the halves and quarters. Practice became a quick market game: "A shopkeeper sells half a kilo of sugar, then a quarter — how much is left?" And the exit ticket was two questions, one easy and one that catches the classic mistake of confusing the number of pieces with the size of each piece.

Nothing in that lesson required classroom technology. The AI contributed structure and variety; the classroom contributed the rotis, the market, and the paper-folding. AI lesson planning for teachers works best when the technology stays in the preparation room and the classroom stays human.

Your First-Week Checklist

If you want to try this yourself, here is the honest starter plan — one week, no overwhelm:

Pick ONE subject and ONE class to experiment with. Don't AI-plan everything at once.
Write your brief template once (topic, class, time, prior knowledge, materials, constraints) and reuse it every day.
Run the three-pass pattern: draft, localize, challenge.
Check every fact and every worked example against the textbook before class.
End every lesson with a two-question exit ticket, and keep the results — they tell you within a week whether the plans are actually working.
Steal the good parts: when a hook or activity lands well, save it in a personal bank for next year. After a term, that bank is worth more than any prompt collection.

A practical note for fellow Pakistani teachers: the free Punjab textbooks are all available online now, so you can read the chapter on your phone while drafting. I keep the full library linked from the Punjab textbooks hub on rehmanahmad.com, and I grab classroom utilities like PDF tools from filecobra.com when I need a printable for class. The tools support the teaching; they never replace it.

The Bottom Line

AI lesson planning for teachers is not about letting a machine teach. It is about letting a machine do the drafting so the teacher can do the teaching — better prepared, less exhausted, with the evening back. My prep time roughly halved, my lessons got more varied, and my students got hooks I would not have invented on a tired evening with a blank page.

But the bargain only holds if you keep the guardrails: textbook as syllabus, every fact verified, no student data shared, and your judgment on every page that reaches a child. Do that, and the AI becomes what it should have been all along — a tireless assistant to a teacher who is still, unmistakably, in charge.

If you try this workflow, start with one lesson this week and judge it by the exit ticket, not by how impressive the plan looked on screen.

Sovereign Intelligence or Perpetual Rental (Volume III): The Global South Compute Bank (GSCB)

Sat, 31 Oct 2026 06:16:37 +0000

The third volume of Sovereign Intelligence or Perpetual Rental designs the institution that the first two volumes implied: a Global South Compute Bank. It starts from a 2026 contrast between an extractive commercial "compute bank", which advances compute against perpetual revenue shares, and a developmental public model offering subsidised access to GPU capacity.

The paper sets out the Bank's institutional charter and a three-tier hub-and-spoke topology of regional gigafactories, national AI factories and a distributed community compute grid. It specifies a balance sheet that holds silicon reserves, forward compute contracts and sovereign data endowments as assets against GPU-hour-denominated liabilities.

It then formalises core banking operations: a Strategic Compute Reserve that aggregates hyperscaler pledges, Compute Purchase Notes, and a fractional compute multiplier that, on illustrative assumptions, lifts usable capacity from 2x to about 5x. A Compute Clearinghouse borrows liquidity-saving mechanisms from payment systems to net cross-time-zone flows and settle coalition surplus by Shapley value. A three-rate corridor, risk-based non-dilutive credit pricing and anti-extractivism guardrails make up a "cognitive monetary policy". A five-year chartering roadmap, a risk assessment and worked numerical illustrations complete the design. The paper is written in a personal capacity.

Read the full paper

Zenodo: https://doi.org/10.5281/zenodo.23808560
Academia: https://www.academia.edu/179937468

KSCCN

Sovereign Land Banking in the Bengal Delta: Khas Land, Private Equity Leasehold, Transit Value Captu

Sat, 31 Oct 2026 06:16:15 +0000

Full title: Sovereign Land Banking in the Bengal Delta: Khas Land, Private Equity Leasehold, Transit Value Capture and Sovereign AI — A Companion Volume

This companion volume applies the generic sovereign public land bank architecture set out in the South Asia study to a single land-scarce deltaic jurisdiction, where arable land amounts to only about 0.045 hectares per person. It traces 230 years of statutory land control, from the Permanent Settlement of 1793 and the nineteenth-century tenancy acts through mid-twentieth-century state acquisition, a 1972 land ceiling and recent consolidation of economic-zone, PPP and investment law under a single investment authority.

The paper examines public khas land and its dual-track allotment to landless households and to enterprise leases, together with the cadastral and forest-tenure complexities of mangrove and hill forest zones. It analyses an economic-zone land bank of 79,019 planned acres and its private-equity leasehold regime: 50-year renewable leases, SPV delegation rights and a fiscal shield covering stamp duty, a developer tax holiday and dividend and capital-gains exemptions.

A transit-oriented land value capture model combines betterment levies with development-rights auctions, with a worked illustration labelled as an assumption. A sovereign data and analytics pipeline reconciles deeds, revenue records and imagery, flags unlawful wetland filling and protects forest-carbon data. Six design recommendations complete the study. The paper is written in a personal capacity and is not investment or financial advice.

Read the full paper

Zenodo: https://doi.org/10.5281/zenodo.23814864
Academia: https://www.academia.edu/179945965

KSCCN

Sovereign Land Banking in South Asia: Legal Genealogy, Title Mechanics, Financial Architecture and A

Sat, 31 Oct 2026 06:15:43 +0000

Sovereign Land Banking in South Asia: Legal Genealogy, Title Mechanics, Financial Architecture and AI Augmentation

Public land across South Asia sits at the junction of colonial revenue law, post-Partition redistribution and today's demand for serviced industrial and urban land. This paper traces that legal genealogy across three South Asian jurisdictions, from the Permanent Settlement of 1793 through post-1947 abolition and land-ceiling statutes, and explains why presumptive deed registration and fiscal revenue records fail to prove title. It also shows how fragmentation, with most holdings small or marginal, traps cultivators in low mechanisation and low income.

On that basis, the paper proposes a generic institutional architecture for a sovereign public land bank. The bank assembles land through pooling, town planning schemes, transferable development rights and regeneration partnerships, balancing an equity mandate for the landless with an enterprise mandate for plug-and-play industrial parks. It finances itself through land value capture.

Cross-border financing structures, including leasehold-as-equity SPVs, REITs and InvITs, land-backed green bonds and exchange-cleared smart leases, admit international capital without alienating sovereign freehold. A four-tier sovereign AI stack supports cadastral reconciliation, suitability screening, mass appraisal and digital twins, and a 60-month roadmap completes the design. Statistics come from official sources, and illustrative projections are labelled as assumptions.

Read the full paper

Zenodo: https://doi.org/10.5281/zenodo.23814784
Academia: https://www.academia.edu/179945903

KSCCN

EnNode Gateway – Smart BACnet and Modbus Integration

Sat, 31 Oct 2026 04:45:24 +0000

How to Connect BACnet and Modbus Devices in a Building Management System

Imagine working on a building automation project where the HVAC controllers communicate through BACnet, energy meters use Modbus RTU, and another set of devices communicates through Modbus TCP.

Everything works independently, but bringing all these devices into one Building Management System (BMS) is not always straightforward.

This is a common situation in commercial buildings and industrial projects. Different manufacturers use different communication protocols, and integrating them into a single monitoring platform can take additional time and effort.

A communication gateway can make this process much easier.

The Challenge of Connecting Different Devices

In a typical BMS project, engineers work with several types of equipment, such as:

Air Handling Units (AHUs)
Variable Frequency Drives (VFDs)
Energy meters
Chillers
Temperature and humidity sensors
Pump and valve controllers

These devices may support different communication protocols. For example, an energy meter might use Modbus RTU over RS485, while the building management server expects BACnet/IP communication.

This creates an integration challenge.

Replacing existing equipment just because it uses a different communication protocol is not always practical. Instead, engineers can use a suitable gateway to connect these devices.

How Does a Protocol Gateway Help?

A protocol gateway acts as a communication bridge between devices that use different protocols.

For example, consider an energy meter connected through an RS485 network. The gateway communicates with the meter using Modbus RTU and makes the required data available to a compatible system through its supported network protocols.

This allows existing field devices to become part of a larger building automation network.

It can also reduce the need for separate communication interfaces for every device.

Introducing the EnNode Gateway

To address these integration requirements, EnSmart Controls offers the EN-MRTU-BIP-LX Nova BACnet Gateway.

The gateway is designed for applications where multiple communication protocols need to work together.

It supports BACnet/IP, Modbus RTU, Modbus TCP, MQTT, and Pulse, making it useful for different building automation and industrial communication requirements.

Some of its important features include:

1. Modbus RTU and Modbus TCP

The gateway supports communication between serial Modbus RTU devices and Modbus TCP-based networks. It also provides master and slave operating modes.

2. BACnet/IP Support

BACnet/IP allows compatible devices and building automation systems to communicate over an Ethernet network. This is particularly useful when integrating field equipment into a centralized BMS.

3. MQTT Communication

MQTT support provides another communication option for IoT-based monitoring applications where data needs to be exchanged with compatible platforms.

4. Two RS485 Ports

The gateway comes with two RS485 communication ports. Both ports can be used simultaneously, which is useful when working with multiple serial networks.

5. Multiple TCP Connections

It supports up to eight simultaneous TCP client connections, allowing multiple compatible systems to communicate with the gateway.

6. Flexible Power Supply

The gateway operates with a 5–36 V DC power supply, offering flexibility during panel design and installation.

A Practical Example: Integrating an Energy Meter into a BMS

Let's take a simple example.

Suppose a commercial building has multiple energy meters installed on different floors. These meters communicate using Modbus RTU through RS485.

The facility management team wants to monitor electricity consumption from a centralized BMS workstation.

The integration process generally involves:

Connecting the energy meters to the RS485 communication network.
Configuring the Modbus communication parameters, including slave IDs, baud rate, parity, and register addresses.
Configuring the gateway according to the required communication setup.
Making the required meter data available to the compatible BMS through the supported protocol.
Checking the readings at the BMS workstation to confirm that the values are being received correctly.

This approach helps integrate existing energy meters without replacing the installed devices.

The same general concept can be applied to other compatible Modbus-based equipment.

Where Can This Gateway Be Useful?

A multi-protocol gateway can be useful in several applications:

Commercial Buildings: Connecting HVAC equipment, energy meters, and controllers to a centralized BMS.
Industrial Projects: Integrating Modbus-based machines and equipment into Ethernet networks.
Energy Monitoring: Collecting data from compatible meters for centralized monitoring.
HVAC Systems: Connecting compatible VFDs, controllers, and other equipment.
IoT Applications: Supporting communication with MQTT-compatible monitoring platforms.

The actual integration depends on the protocols, device capabilities, and configuration requirements of each project.

Final Thoughts

In building automation, the challenge is not always installing new equipment. Sometimes, the real challenge is getting the existing equipment to communicate with one another.

A suitable communication gateway can help simplify this process and make system integration more manageable.

For BMS engineers and system integrators working with different communication protocols, understanding how gateways work is an important part of designing reliable automation systems.

If you are working on a project involving BACnet, Modbus, or IoT integration, the EnNode Gateway is worth exploring.

Product details: https://ensmart.ai/ennode-gateway

Developed by: EnSmart Controls

Python for commerce students, from a former bio kid

Sat, 31 Oct 2026 04:30:00 +0000

On 18 September 2026 I was the resource person for a workshop called "Basic Python for Financial Analysis".
The audience was B.Com (Hons.) students at Ethiraj College for Women.

A few years ago I was a bio-maths student.
Now I was the one at the front, talking about Python.
Life is strange like that.

This post isn't a recap of the workshop.
It's about why I think Python for commerce students is a good idea, and what a beginner path could look like.
All of it is about analysis skills.
None of it is investing advice. Please don't buy anything because of a moving average you calculated on a Tuesday.

Photo: Markus Winkler on Unsplash

The other side of the room

In class 12 I did biology and maths.
Then I switched to computer science.

In a class full of CS students, I was the non-CS kid.
I felt behind. Properly behind.
So in my first month of college I taught myself more than 12 programming languages.
freeCodeCamp was my biggest teacher, and I'm still grateful to it.
(The long version is in switching from biology to computer science.)

What I learned from that month is simple.
The gap between "CS student" and "not a CS student" is smaller than it looks from the outside.
Most CS students know the basics: some Python, general IT.
The class 11 and 12 CS syllabus can be covered in a month or two.

So when someone says "I'm from commerce, coding isn't for me", I don't really buy it.
I was from biology. It wasn't for me either. Until it was.

Why Python, if you already have Excel

Excel is great. I'm not here to start a fight with Excel.
But spreadsheets get painful when the data gets big, or the same steps repeat every month.

CPA Australia's magazine INTHEBLACK ran a piece on why accountants should learn Python.
It says "Python is more flexible than Excel, and it offers greater efficiency, scalability and auditability."
It also says Python lets accountants "automate tasks, especially those that are repetitive and involve clear logical steps."
And that "digital and data skills are now considered a core competency."

That last line is the one I'd underline for a B.Com student.
You're not trying to become a software engineer.
You're trying to be the person in the finance team who doesn't dread a 50,000-row file.

The word I like in that quote is "auditability".
A formula buried in cell K482 is hard to check.
A script you can read top to bottom is easier to check, rerun and hand to someone else.

The official Python tutorial calls Python "an easy to learn, powerful programming language".
It's also free: the interpreter and standard library are "freely available" for all major platforms.
For students, free matters. It certainly mattered to me.

You don't even need to install anything

The first hurdle for beginners is usually setup, not code.
Installing things, paths, versions, the usual suffering.

Google Colab skips that.
Its FAQ describes it as "a hosted Jupyter Notebook service that requires no setup to use", and says "Colab is free of charge to use."
You open a browser, sign in, and type code.
The FAQ is also honest that free resources are "not guaranteed and not unlimited", which is fine for a beginner reading a CSV.

Photo: Zach Graves on Unsplash

A beginner path, from spreadsheet to pandas

This is my opinion of a sensible order, not a syllabus.
Each step is small. That's the point.

Think in tables first. You already do this in Excel. Rows are records, columns are fields. That habit carries straight over.
Learn just enough Python. Variables, lists, loops, functions. A week of evenings, not a semester.
Meet pandas. pandas is the library that gives Python spreadsheet-like tables. Its own 10 minutes to pandas guide is "a short introduction to pandas, geared mainly for new users". It covers viewing, selecting, grouping, pivot tables, time series, and reading and writing CSV and Excel files.
Read a CSV of prices. Download a price history as a CSV and load it. Look at it. Check the dates came in as dates.
Calculate something simple. Daily returns and a moving average are a good first exercise. Not because they predict anything, but because they make you handle dates, gaps and windows.

Here is what step 5 can look like:

import pandas as pd

prices = pd.read_csv("prices.csv", parse_dates=["Date"], index_col="Date")
close = prices["Close"]

daily_return = close.pct_change()             # 0.012 means 1.2%
moving_avg = close.rolling(window=20).mean()  # 20-day average

print(daily_return.describe())
print(moving_avg.tail())

It assumes a CSV with a Date column and a Close column.
pct_change is the "fractional change between the current and a prior element", so the first row is empty because there's nothing before it.
rolling looks back "the length of the window from the current observation".
With a 20-day window, the first 19 averages are empty too.
Seeing those blanks and understanding why they're there is half the lesson.

One small gotcha: in current pandas, pct_change no longer fills missing values for you.
The docs suggest calling ffill() first if your data has gaps.
That's exactly the kind of detail you only learn by running the code and squinting at the output.

Free resources I'd point people to

I won't pay for something I can get free, and I won't ask students to either.

The Python tutorial. One honest warning: it says it's "designed for programmers that are new to the Python language, not beginners who are new to programming". Use it as a reference once you've started somewhere gentler.
10 minutes to pandas. It will take longer than ten minutes. It's still the best map of what pandas can do.
freeCodeCamp's Learn Data Analysis with Python. A free four-hour course by Santiago Basulto. It covers reading data "from multiple sources (CSVs, SQL, Excel)", cleaning it with NumPy and pandas, and visualising it with Matplotlib and Seaborn.
Google Colab. To run all of the above without installing anything.

freeCodeCamp was my biggest teacher. Biased? Yes. Wrong? I don't think so.

Being at the front of the room

Same month, same college:
I was also the Chief Guest at the AURORA '26 valedictory ceremony at Ethiraj.
Which is a lot of stage time for someone who used to feel like the odd one out in his own class.

If there's one thing I'd want a commerce student to take away, it's this.
You're not late. You're not in the wrong stream.
You're one CSV file away from starting.

FAQ

Do commerce students need to learn coding?

Nobody needs to. But data skills are increasingly expected in accounting and finance roles, and Python is a friendly way in.

Is this financial advice?

No. Returns and moving averages here are exercises in handling data, not signals to buy or sell anything.

What's the fastest way to start?

Open Google Colab, load a small CSV with pandas, and print the first few rows. Then make it do one useful thing.

Sources

What next

The full story of the switch: switching from biology to computer science, with zero plan.
And how we got through the early days on free AI trials: dozens of email accounts and zero shame.

Your Tests Are Green and Prove Nothing: 4 Signs You're Testing the Mock

Sat, 31 Oct 2026 03:38:56 +0000

Coverage says 94%. Every test is green. You deploy on Friday afternoon, and by Monday a customer has found a bug in the exact function you "tested".

When you open the test, the reason is obvious in hindsight. The test never ran your code. It ran a fake version of everything around it and then asserted that the fake behaved like a fake.

Here are four ways this happens, and a check you can do in a minute to see how many of your own tests are guilty.

1. You Mocked the Thing You Are Testing

// pricing.ts
export function applyDiscount(total: number, code: string) {
  return code === 'SAVE10' ? total * 0.9 : total;
}

// checkout.test.ts
import * as pricing from './pricing';

vi.spyOn(pricing, 'applyDiscount').mockReturnValue(90);

test('applies discount at checkout', () => {
  expect(checkout(100, 'SAVE10')).toBe(90);
});

This passes if applyDiscount is correct. It also passes if applyDiscount returns NaN, because the test replaced it with a hard-coded 90. You are testing that checkout can return the number you handed it.

Fix: mock what is outside your code, such as network, clock and payment providers. Run your own logic for real.

2. You Assert the Calls, Not the Outcome

test('saves the user', async () => {
  await createUser({ email: '*Emails are not allowed*' });
  expect(db.insert).toHaveBeenCalledWith('users', { email: '*Emails are not allowed*' });
});

This test proves the function called insert with those arguments. It does not prove a user exists. If someone renames the table, adds a required field or changes the query, this test keeps passing against the mock while real users stop being saved.

It also fails for the wrong reason. Refactor the internals without changing behavior, and it turns red, so people learn that failing tests are noise.

Fix: assert what a user or caller would observe.

test('saves the user', async () => {
  await createUser({ email: '*Emails are not allowed*' });
  const user = await findUserByEmail('*Emails are not allowed*');
  expect(user?.email).toBe('*Emails are not allowed*');
});

3. The Fake Database Only Says Yes

A mocked database returns whatever you tell it to. A real one has rules:

A unique index rejects duplicate emails.
A required field rejects a missing value.
A foreign key rejects an ID that does not exist.
A query with a typo in a field name returns nothing.

None of these exist in a mock, so none of these bugs can appear in your tests. They show up in production, on the first real duplicate signup.

Fix: for anything that touches storage, test against a real database, either a throwaway local instance or an in-memory one with the same engine, reset between tests. It is slower than a mock, but it is the only thing that can fail the way production fails.

test('rejects a duplicate email', async () => {
  await createUser({ email: '*Emails are not allowed*' });
  await expect(createUser({ email: '*Emails are not allowed*' })).rejects.toThrow();
});

You cannot write that test against a mock that always resolves.

4. Snapshots Approved Without Reading

expect(renderInvoice(order)).toMatchSnapshot();

A snapshot records whatever the output is today and fails when it changes. It does not know whether today's output is correct. When it fails, the usual reaction is to press "update" and move on, so the test stores bugs as the expected answer.

Fix: use snapshots for small, stable things, and assert the fields that matter for anything involving money, permissions or dates:

const invoice = renderInvoice(order);
expect(invoice.total).toBe(118.0);
expect(invoice.lines).toHaveLength(2);

The 60-Second Sabotage Check

Here is how to find out whether a test protects you. Take a function you care about, break it on purpose, and run its tests.

export function applyDiscount(total: number, code: string) {
  return total; // sabotage: discount never applies
}

Then ask one question: did a test fail?

If yes, that test is doing its job.
If no, you have found a test that would have stayed green while the feature was broken in production.

Revert the change, and fix or delete the test that did not notice. Try this on three important functions and you will learn more about your suite than coverage ever told you. The formal version of this idea is called mutation testing, and tools exist that automate it, but doing it by hand on your most critical code is a good start.

What to Mock, and What Not To

Mock it	Run it for real
Network calls to third parties	Your own business logic
The clock and random numbers	Your database queries
Email and SMS sending	Validation and permission rules
Payment providers	Anything that can fail on real data

The rule is that you mock the edges, the places where your code talks to someone else, and keep everything in the middle real.

The Rule

A test that cannot fail when the code is wrong is not a test. Mock the world outside your app, assert outcomes instead of calls, and use sabotage to check whether your tests notice.

Quick audit: pick the three functions that would hurt most if they broke, such as pricing, permissions and sign-up. Break each one on purpose. Count how many tests turn red. If the answer is zero for any of them, that is your next ticket.

If you want a Next.js starting point to build and test on, you can browse my templates on pixelanas.com.

Get the templates: https://pixelanas.gumroad.com

What is the most misleading green test you have ever found? Share it in the comments.

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

How to Change the WAF Web Console Listening Port When SafeLine Stays on 9443

Sat, 31 Oct 2026 02:47:24 +0000

Changing the WAF web console listening port looks like a one-line edit, but the SafeLine deploy guide only treats one environment key as that port. This troubleshooting note covers one concrete misconfiguration: the operator stored a new port in MGT_PROXY, left MGT_PORT at 9443, and opened a browser URL built from the MGT_PROXY number. The management page did not load. The fix is confirmed when the browser shows the web console on the port named by MGT_PORT, and the administrator reset command still prints a usable login.

SafeLine is a self-hosted web application firewall. Deployed in front of an application, it works as a reverse proxy: clients reach the WAF first, and the WAF filters and monitors HTTP traffic before a request is forwarded. That protection path is not the management console. The console is the admin page documented in the deploy guide at https://docs.waf.chaitin.com/en/GetStarted/Deploy. That guide names the console port with MGT_PORT, described as the web console port to be used. The sample .env sets MGT_PORT=9443, and the Use Web UI section says to open https://<safeline-ip>:9443/. Those two statements are the pair you have to keep aligned.

The misconfiguration

Manual setup creates /data/safeline, downloads compose.yaml, and writes .env in that directory. The sample sets MGT_PORT=9443 and MGT_PROXY=0, plus directory, image, database password, subnet, and token values. MGT_PORT is the web console port to be used. MGT_PROXY is the number of console proxy layers. The same guide says MGT_PROXY should only be used when configuring the proxy for the console, and that the default 0 means no proxy is configured. See https://docs.waf.chaitin.com/en/GetStarted/Deploy.

The failed change ignored that split. The operator wanted the console off the sample port, replaced 0 in MGT_PROXY with the desired port, saved the file, and browsed to https://<safeline-ip>: plus that MGT_PROXY value. MGT_PORT was still 9443. The deploy guide never says MGT_PROXY selects the listening port. A non-zero value is a proxy-layer count for a real console proxy setup. Writing a port there does not move the URL under Use Web UI.

A related mistake shows up after login. The application guide at https://docs.waf.chaitin.com/en/GetStarted/AddApplication tells you to open Applications, choose Add Application, and enter Domain, Port, and Upstream. Port there is the port SafeLine will listen on for the original app, such as 80 or 443, with SSL checked for HTTPS apps. That field is not MGT_PORT. Changing it does not rewrite the console address https://<safeline-ip>:9443/.

What to compare before you call it a port change

Use the deploy guide as the checklist and touch only the key it defines as the console port.

Open .env in the SafeLine directory, shown as /data/safeline in the manual steps. Read MGT_PORT first. That is the web console port to be used, and the published example is 9443. Read MGT_PROXY next. Leave it at 0 unless you are actually configuring proxy layers for the console. Do not store a listen port in MGT_PROXY. Do not use the Applications Port field as the console setting. That field belongs to the protected site.

The guide applies the environment file when you launch with docker compose up -d from the SafeLine directory. The worked example then opens the console at https://<safeline-ip>:9443/, which matches MGT_PORT=9443. If MGT_PORT is still 9443, that is the documented console address, even if another number was typed into MGT_PROXY or into an application form. The sources do not publish a separate post-install migration log, a firewall recipe, or a certificate recipe for an alternate console port. They also do not show a command whose only job is to rebind the console after a later edit. If the page fails on some other number, treat that as a URL mismatch against MGT_PORT, not as proof that the console moved.

If you are still in the environment-writing step, declare the console port only with MGT_PORT, then launch with the documented docker compose up -d command, and open the console with that same port value. The official success case in the guide is port 9443. Keep the browser pattern identical to Use Web UI, and do not assume an undocumented log line will announce the bind.

The screen that confirms the fix

Restore MGT_PROXY to 0 if you are not configuring a console proxy. Point the browser at the port stored in MGT_PORT. In the documented installation that value is 9443, so the confirming page is https://<safeline-ip>:9443/. The deploy guide says opening this page is how you use the web UI after installation. Seeing that console page is the first confirmation. A connection error or a timeout on any other port is the mismatch, not a successful port move.

The second confirmation is the account step, not a guessed log path. Run docker exec safeline-mgt resetadmin. When it succeeds, the guide says you must remember the content, then shows the initial username admin, the initial password, and Done. Log in with that username and password on the console page that just loaded. A completed login on the MGT_PORT URL is the screen that proves you are on the web console the install guide configured.

Do not use a block page as that proof. The application guide says a blocking page means SafeLine defended a test attack against a protected site, and that attack detail is viewed from the web console attack list. A block page means you reached a protected application flow. It does not confirm that MGT_PORT changed, and it does not confirm that MGT_PROXY was a valid place to store a port.

If resetadmin succeeds but the browser still targets the wrong port, the account step is not the failure. Read MGT_PORT again. The password block only helps after the console page itself is the one from Use Web UI.

Automatic install does not add a different confirmation. After the documented install command finishes, the deploy guide sends you to Use Web UI, which is the same https://<safeline-ip>:9443/ page. The success text does not print an alternate console port.

What this check does not claim

The home overview at https://docs.waf.chaitin.com/en/home describes SafeLine as a self-hosted WAF and reverse proxy with defenses for web attacks, bot abuse defense, HTML and JS code encryption, IP-based rate limiting, and a web access control list. None of those behaviors is a console port switch. Rate limiting, CAPTCHA challenge, authentication challenge, and dynamic protection are traffic controls for protected apps, not substitutes for MGT_PORT.

This note does not claim that every numeric port is suitable, and it does not add steps the deploy guide does not contain. If the console page does not load on the port written in MGT_PORT, stop and re-check the variable names rather than stacking rewrites that the sources do not describe. After the console loads, protecting an application is still a separate task: add Domain, Port, and Upstream, then resolve the domain to the SafeLine server, as https://docs.waf.chaitin.com/en/GetStarted/AddApplication describes.

Why does the console still open on 9443 after I edited the environment file?

Because the sample and the Use Web UI section both use 9443, and that number comes from MGT_PORT, not from whichever numeric field you edited. If MGT_PORT is still 9443, the documented console URL is still https://<safeline-ip>:9443/. A change to MGT_PROXY or to an application Port does not replace that page. The variable definitions are in https://docs.waf.chaitin.com/en/GetStarted/Deploy.

Is the application port the same as the web console port?

No. In Add Application, Port is the port SafeLine listens on for the original app, with 80 or 443 given as examples. The web console port is MGT_PORT in .env. Mixing those fields is the misconfiguration above. The application fields are documented at https://docs.waf.chaitin.com/en/GetStarted/AddApplication.

What does MGT_PROXY change if it is not the listen port?

The deploy guide defines MGT_PROXY as the number of console proxy layers. It should only be used when configuring the proxy for the console. The default is 0, which means no proxy is configured. It is not documented as the web console listening port.

Which screen confirms the console port is the one I intended?

Load https://<safeline-ip>: followed by the MGT_PORT value. For the documented example, that is https://<safeline-ip>:9443/, and the web console page should appear. Then run docker exec safeline-mgt resetadmin and confirm the initial username admin and the Done line before you log in. That loaded console, not a timeout on another port, is the confirmation described in https://docs.waf.chaitin.com/en/GetStarted/Deploy.

Do I need a new administrator password after correcting the port?

Only if you run the documented reset. docker exec safeline-mgt resetadmin prints the initial password and Done. Correcting MGT_PROXY back to 0, or opening the URL that already matches MGT_PORT, does not by itself rotate that password. Use the credentials the command prints if you choose to reset, and use them on the console page that matches MGT_PORT.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

SafeLine website: https://ly.cyberserval.tech/MqhYdmI
Demo: https://demo.waf.chaitin.com:9443/statistics
Official docs: https://docs.waf.chaitin.com/en/home
GitHub: https://github.com/chaitin/SafeLine
Pro offer: https://cyberserval.tech/landing/lto

Why I Change the WAF Web Console Listening Port Before Turning Protection On

Sat, 31 Oct 2026 02:46:53 +0000

Before I turn protection on for a live site, I walk a decision checklist. The step I no longer skip is the management listener. Learning how to change the WAF web console listening port belongs in that checklist, because the console is where I will later read blocks, challenges, and attack detail. If I cannot open it on a port I chose, I am not ready to point a domain at the proxy.

SafeLine is a self-hosted web application firewall. Placed in front of an application, it works as a reverse proxy: clients reach SafeLine first, it filters and monitors HTTP and HTTPS traffic, and it forwards traffic it treats as safe to the original application. The product introduction lists defenses for web attacks, proactive bot abuse defense, HTML and JS code encryption, IP-based rate limiting, and a web access control list. Those controls are useless to me if the console listener was an accident.

Set the console port before the first launch

The manual deploy page is the place that defines this choice. In the environment file, MGT_PORT is the web console port to be used. The sample sets MGT_PORT=9443, and the same page tells you to open https://<safeline-ip>:9443/ after startup. I treat 9443 as the documented sample, not as a port every host must keep. When that port is already taken, or when my access policy expects the console elsewhere, I change MGT_PORT in .env before I run docker compose up -d. These pages do not describe a console-port switch inside the application dialog, so I do not wait until after DNS and hope one appears.

The automatic installer is a narrower path. The deploy guide gives one command and then sends you to the web UI, which it shows on port 9443. It does not document a port flag on that command. If I need a non-default console port, I use the manual environment file, where MGT_PORT is explicit, and I decide it before protection is turned on. See the deploy guide: https://docs.waf.chaitin.com/en/GetStarted/Deploy

MGT_PROXY is a different knob. The guide defines it as the number of console proxy layers, to be used only when configuring a proxy for the console. The default is 0, which means no proxy is configured. Choosing another MGT_PORT does not, by itself, mean I should change MGT_PROXY.

Keep that port off the public site path

Turning protection on is an application change, not a console login. In Applications, Add Application asks for three facts. Domain is the original app domain, hostname, or IP. Port is the port SafeLine will listen on for that app, such as 80 or 443, with the SSL option checked for HTTPS apps. Upstream is the real address used to forward cleaned traffic. After that, the domain is resolved to the IP of the server where SafeLine runs. Visitors then reach the site through SafeLine. The application steps are documented at https://docs.waf.chaitin.com/en/GetStarted/AddApplication

Those fields are easy to mix up with MGT_PORT. They are not the same decision. If I set the application listen port to the console port, administration and the public site fight over one listener. My order is console port first, application listen port second, and DNS last.

I also refuse to add an application until the host matches the documented minimums: Linux, x86_64 or arm64, Docker 20.10.14 or above, Docker Compose 2.0.0 or above, 1 CPU core, 1 GB of memory, 5 GB of disk, and a CPU with ssse3. The deploy page lists checks such as uname -m, docker version, docker compose version, free -h, df -h, and lscpu | grep ssse3. I run the ones that apply to this machine instead of assuming a laptop test equals the server.

ARM is a hard stop in that same page. SafeLine installed on ARM requires a Pro license to work properly, and the Personal Edition is not supported on ARM. If I am on ARM and that license does not apply, I stop before DNS. The LTS choice is equally explicit: RELEASE=-lts selects the LTS line, which the guide says will no longer be maintained starting from 9.1.0-LTS on 14 August 2025. It recommends moving to the latest version, and waiting about a month after a new release if I want caution. I write that choice down before traffic depends on it.

Secrets come before exposure. The manual steps generate DETECTOR_MGMT_TOKEN and MGT_INTERNAL_TOKEN as 64-character hex values, generate a 16-character alphanumeric DETECTOR_AES_KEY, write them into .env, and set chmod 600 on that file. I do not launch with the sample placeholders still in place. After docker compose up -d, which can take several minutes, I open the console on the port I set. I run docker exec safeline-mgt resetadmin and I keep the initial username and password it prints. The guide shows that initial username as admin. If that page does not load, the listening-port decision is still open, and protection is not ready.

Name the protection you are actually turning on

The introduction lists coverage for SQL injection, XSS, code injection, OS command injection, CRLF injection, LDAP injection, XPath injection, RCE, XXE, SSRF, path traversal, backdoor, bruteforce, HTTP flood, and bot abuse: https://docs.waf.chaitin.com/en/home

The same pages name rate limiting, CAPTCHA challenge, authentication challenge, and dynamic protection. Rate limiting throttles traffic over defined limits, including DoS attempts, bruteforce attempts, and traffic surges. CAPTCHA is documented as a challenge that lets human users through while blocking crawlers and bots. Authentication challenge, when turned on, requires a password or the visitor is blocked. Dynamic protection, when turned on, dynamically encrypts HTML and JS on each visit. I pick the controls this application needs. I do not flip every switch because the container started.

Before I call the site protected, I use the documented probes: a SQL injection query, an XSS payload, a path traversal sequence, a code injection string, and an XXE doctype, with my own domain in place of the example. A blocking page means that request was defended. I then open the attack list in the console and click detail. An empty list sends me back to domain, listen port, upstream, and DNS. It does not send me to a victory message.

The checklist I keep is short. Confirm the host, and stop on ARM if the documented license requirement is not met. Set MGT_PORT to the console port I will use, and leave MGT_PROXY at 0 unless the console itself is proxied. Generate the documented secrets and restrict .env. Launch, log in with the resetadmin output, and only then add Domain, Port, and Upstream. Resolve DNS last. Judge the result from the blocking page and the attack detail view.

How do I change the WAF web console listening port?

Set MGT_PORT in the SafeLine .env file used by the manual compose deploy. The deploy guide defines that variable as the web console port to be used and shows 9443 in the sample, with the console at https://<safeline-ip>:9443/. Put the port you want in MGT_PORT, then start with docker compose up -d. That is a console environment setting. It is not a field in Add Application, and these pages do not describe a later port control in the UI.

Is the web console port the same as the application listen port?

No. MGT_PORT is only the web console port. In Add Application, Port is what SafeLine listens on for the protected app, such as 80 or 443, and HTTPS apps need the SSL option. Upstream is the real address that receives forwarded traffic. Changing the console port does not change the public site listener.

What should I verify before I turn protection on?

Match the documented host minimums, including Docker 20.10.14 or newer, Docker Compose 2.0.0 or newer, memory, disk, and ssse3. On ARM, confirm the Pro license requirement, because the Personal Edition is not supported there. Generate the documented secrets, open the console on your MGT_PORT, and log in with the account printed by docker exec safeline-mgt resetadmin. Add the application and point DNS at the SafeLine server only after that login works.

Does a different console port require MGT_PROXY?

No. MGT_PROXY is the number of console proxy layers. Use it only when you are configuring a proxy for the console. The default of 0 means no proxy is configured. A custom MGT_PORT does not imply a console proxy.

How do I know the protection decision worked?

Send the documented SQL injection, XSS, path traversal, code injection, and XXE test requests to your own domain. Expect the blocking page, then open the console attack list and click detail. If you cannot open the console, fix the listening port and the admin login before you judge the site protected.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

SafeLine website: https://ly.cyberserval.tech/MqhYdmI
Demo: https://demo.waf.chaitin.com:9443/statistics
Official docs: https://docs.waf.chaitin.com/en/home
GitHub: https://github.com/chaitin/SafeLine
Pro offer: https://cyberserval.tech/landing/lto

How to Reset the WAF Admin Account Inside Docker

Sat, 31 Oct 2026 02:37:39 +0000

Losing the SafeLine console password usually starts with a reasonable but wrong edit. After installation, the web UI is opened at https://<safeline-ip>:9443/, and the deploy guide does not store that login in the Compose environment file. Resetting the administrator account is a container command. The failure mode below is one concrete mix-up: treating POSTGRES_PASSWORD as the console password, then trusting a restart that never printed a new admin credential.

What was misconfigured

A manual install keeps SafeLine configuration and data in a directory you create. The deploy guide at https://docs.waf.chaitin.com/en/GetStarted/Deploy uses /data/safeline as the example. Inside it, .env holds SAFELINE_DIR, IMAGE_TAG, MGT_PORT, POSTGRES_PASSWORD, SUBNET_PREFIX, and several generated secrets. That same guide defines POSTGRES_PASSWORD as the Postgres database initialization password. It is consumed when the database is initialized. It is not the account you type into the management UI.

The misconfiguration looks like this. The operator cannot log in, opens .env, replaces POSTGRES_PASSWORD, optionally rewrites DETECTOR_MGMT_TOKEN or MGT_INTERNAL_TOKEN, and runs docker compose up -d again. Compose can bring the stack process up. That result does not print an administrator username or a console password. The web account was never that database variable, so the edited string is the wrong secret for the login form.

File mode is a related dead end. The guide sets .env to mode 600 and restricts resource directories such as resources/mgt and resources/postgres/data. Those permissions protect local secrets and sockets. Changing them does not rotate the console user.

Reset the account inside the management container

Use the procedure in the deploy guide, in order.

Confirm the host meets the documented dependencies before you blame the password command: Linux, x86_64 or arm64, Docker 20.10.14 or above, and Docker Compose 2.0.0 or above. The guide also lists a minimum of 1 core CPU, 1 GB memory, and 5 GB disk, plus the ssse3 CPU flag. Those checks explain a stack that never became ready. They are not a second password store.

From the SafeLine directory that contains compose.yaml and .env, start the services with docker compose up -d. The guide warns that this can take several minutes. When it finishes, request the administrator account from inside the management container:

docker exec safeline-mgt resetadmin

The container name in that command is safeline-mgt. Do not point docker exec at the Postgres image named in .env, and do not expect the automatic installer shell to reprint the password later. The documented recovery for the administrator account is this exec, described under Get Administrator Account in https://docs.waf.chaitin.com/en/GetStarted/Deploy.

The screen that confirms the fix

Success is a terminal screen, not a Compose health line. The deploy guide says that after the command succeeds you must remember the printed content. The confirming text begins with the sentence Please must remember this content. It then prints three [SafeLine] lines: initial username admin, initial password, and Done. The password in the guide is shown masked. On your host, copy the characters that appear in that password field. Asterisks in the documentation are not the credential.

If that remembered-content screen is absent, the reset is not confirmed. Do not fall back to POSTGRES_PASSWORD, and do not paste a token from .env into the login form. DETECTOR_MGMT_TOKEN and MGT_INTERNAL_TOKEN are internal values written during setup. The guide does not present them as console passwords.

After the screen is present, open the console with HTTPS on the SafeLine host and the console port. The documented URL is https://<safeline-ip>:9443/. MGT_PORT is defined as the web console port, and the sample .env sets it to 9443. If you changed MGT_PORT before startup, use that port instead. MGT_PROXY is the number of console proxy layers. The sample keeps it at 0 when no console proxy is configured. It does not replace resetadmin.

The guide then says to enter the password from the previous step, after which you are logged into SafeLine. A successful login with that exact password is the second confirmation. Seeing a block page on a test request only proves that a protected application filtered an attack, as described in https://docs.waf.chaitin.com/en/GetStarted/AddApplication. It does not prove that the admin reset ran.

What not to reset by accident

SafeLine is a self-hosted web application firewall, per https://docs.waf.chaitin.com/en/home. Deployed in front of an application, it is a reverse proxy: clients reach SafeLine first, malicious HTTP and HTTPS traffic is filtered, and safe traffic is forwarded to the upstream. The same overview lists defenses against attacks such as SQL injection, XSS, command injection, path traversal, SSRF, and brute force, plus rate limiting, CAPTCHA challenge, authentication challenge, and dynamic HTML and JS protection. None of that is configured by the admin reset command.

Application proxy settings are entered after login. The protecting-applications guide tells you to open Applications, add an application, and set domain, listen port, and upstream. Resetting the console user does not document a change to those fields.

Do not uninstall to recover a password. Uninstall, in the same deploy guide, is docker compose down in the SafeLine directory and then removal of that directory. That deletes local configuration and data. It is a different operation from docker exec safeline-mgt resetadmin.

Close the loop with the original mistake

Before you leave the host, check four facts against the screen you just saw. The stack was started with docker compose up -d. The reset targeted safeline-mgt. The terminal showed the remember-this-content notice, username admin, a password, and Done. The browser used HTTPS and MGT_PORT, normally 9443, with the password copied from that screen rather than from POSTGRES_PASSWORD.

Why does editing POSTGRES_PASSWORD fail to reset the console admin?

The deploy guide defines POSTGRES_PASSWORD as the Postgres initialization password in .env. The documented way to obtain the console administrator account is docker exec safeline-mgt resetadmin. A Compose restart can leave the web password unchanged because that variable was never the console credential.

How do I know the container reset actually finished?

The confirming screen is the output documented for resetadmin: the notice to remember the content, then [SafeLine] lines for initial username admin, initial password, and Done. No other log in the install guide is described as that credential. If those lines are missing, there is no new admin password to type.

Which URL matches the password I just reset?

Log in at https://<safeline-ip>:9443/ unless MGT_PORT in .env was set to another console port. Use HTTPS. The upstream site you are protecting is not the management UI, and a guess on the application listen port will not submit this credential to the console.

Can I reset the admin account before docker compose up finishes?

The guide places Get Administrator Account after Launch SafeLine. Run docker compose up -d first and allow the start, which may take several minutes. resetadmin is an exec into safeline-mgt, so the management container has to be there for the command to return the success screen.

Will this admin reset delete applications or replace the database password?

The documented command prints an initial username and password for the console. It does not say that applications, upstreams, or POSTGRES_PASSWORD are rewritten. Removing the install directory is the uninstall path, and that path does delete SafeLine data, so keep uninstall and admin reset separate.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

SafeLine website: https://ly.cyberserval.tech/MqhYdmI
Demo: https://demo.waf.chaitin.com:9443/statistics
Official docs: https://docs.waf.chaitin.com/en/home
GitHub: https://github.com/chaitin/SafeLine
Pro offer: https://cyberserval.tech/landing/lto

Why I Run a Checklist Before Turning Protection On

Sat, 31 Oct 2026 02:37:07 +0000

I do not turn protection on in the same hour I install a web application firewall. SafeLine sits in front of the origin as a reverse proxy, so a rushed cutover can lock operators out of the console or send visitors to the wrong upstream. The product documentation describes SafeLine as a self-hosted WAF that filters and monitors HTTP traffic between a web application and the Internet, blocking malicious requests and stopping unauthorized data from leaving the app by applying policies that separate malicious traffic from safe traffic (https://docs.waf.chaitin.com/en/home). That architecture is why I keep a decision checklist, and why the first operational question is how to reset the WAF admin account inside Docker before any site depends on the proxy.

Confirm the host before you trust the console

The deploy guide sets a floor I will not negotiate: Linux, x86_64 or arm64, Docker 20.10.14 or above, Docker Compose 2.0.0 or above, and at least 1 CPU core, 1 GB of memory, and 5 GB of disk. The CPU must support ssse3. The same page lists the checks I actually run: uname -m, docker version, docker compose version, processor and memory inspection, df -h, and an lscpu filter for ssse3 (https://docs.waf.chaitin.com/en/GetStarted/Deploy). If any line fails, protection stays off. On ARM, that guide states that SafeLine requires a Pro license to work properly and that the Personal Edition is not supported on ARM. I treat that as a stop, not a footnote. I also decide the release track before launch. The guide says the LTS line will no longer be maintained starting from 9.1.0-LTS (14 August 2025) and strongly recommends an upgrade to the latest version. I do not put a new site behind an unmaintained image tag just because the compose file still accepts RELEASE=-lts.

Recover the admin account while the shell still works

After the stack is up, the deploy guide says to open the web console at https://<safeline-ip>:9443/ and to get the administrator account with this command:

docker exec safeline-mgt resetadmin

A successful run tells you to remember the printed content. It shows an initial username of admin, an initial password, and a done line. I run that command from the Docker host, store the password outside the server, and log in once before I add an application. This is the documented way to obtain the administrator account inside Docker. I do not invent a database edit, a second container name, or a custom reset flag. If the command fails, the container is unhealthy, or I cannot read the password, I am not ready to proxy production traffic. The management UI is how I will later add sites and read the attack list, so a console I cannot enter is a failed checklist, not a minor inconvenience.

Secrets sit next to that login drill. A manual install keeps configuration in a directory such as /data/safeline, including POSTGRES_PASSWORD and the generated detector and management tokens, and the guide sets .env to mode 600. MGT_PORT is the console port, 9443 in the sample. MGT_PROXY is the number of console proxy layers and should stay at 0 unless a console proxy is actually being configured (https://docs.waf.chaitin.com/en/GetStarted/Deploy). Before protection is on, I decide who can reach port 9443 and who can read .env. I do not change MGT_PROXY to paper over a login problem.

Decide the proxy path, then decide which controls to enable

SafeLine is an nginx-based reverse proxy. It receives traffic for the original site, cleans malicious traffic, and forwards the remainder to the original application (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). In the Web Admin Console, Add Application asks for Domain, Port, and Upstream. Domain may be a domain name, a hostname, or an IP. Port is what SafeLine will listen on, such as 80 or 443, and HTTPS apps need the SSL option checked. Upstream is the real address used for forwarding. After those values are saved, the domain must resolve to the SafeLine server. If DNS still points at the origin, the site is not protected. If Upstream is wrong, the site is down. I write the three values down and test resolution before I call the change complete.

The feature choice is a separate decision. Documented capabilities include defenses against SQL injection, XSS, code injection, OS command injection, CRLF injection, LDAP injection, XPath injection, RCE, XXE, SSRF, path traversal, backdoor, brute force, HTTP flood, and bot abuse, plus IP-based rate limiting and a web access control list (https://docs.waf.chaitin.com/en/home). The feature list also describes CAPTCHA so human visitors can pass while crawlers and bots are blocked, an authentication challenge that requires a password or else blocks the visitor, and dynamic protection that encrypts HTML and JS on each visit. I do not turn every one of those on during the first cutover. Challenges, dynamic encryption, and tight rate limits change what a legitimate user receives. My default is to prove the proxy and basic attack handling first, and to enable a challenge or dynamic encryption only after I can name the user impact.

I prove the path with the samples in the application guide, not with live customers. That page shows test requests for SQL injection, XSS, path traversal, code injection, and XXE, and says a blocking page means the attack was defended. I then open the console attack list and a detail view (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). A normal request should reach the upstream. A documented attack-style request should block or at least show up in that list. If neither happens, I do not declare protection on. I correct the proxy path and repeat the test.

My go or no-go order is fixed. The host meets the documented CPU, memory, disk, Docker, Compose, and ssse3 requirements, and the ARM license rule is already satisfied if the server is ARM. docker exec safeline-mgt resetadmin has printed an admin password I have stored, and I have logged in on port 9443. Domain, listen port, and upstream are recorded, and DNS points at the SafeLine host. I know which extra controls stay off on day one. One safe request is forwarded and one documented attack-style request is visible as a block or in the attack list. Any failed line means protection stays off.

How do I reset the WAF admin account inside Docker?

On the Docker host, run the command from the deploy guide: docker exec safeline-mgt resetadmin. Success output shows an initial username of admin and an initial password. Store that password and log in at https://<safeline-ip>:9443/ before you add an application. These pages do not describe another reset method, so I do not improvise one inside the database container.

No. Adding an application and reading the attack list both happen in the Web Admin Console. If resetadmin fails or port 9443 is unreachable from your admin network, leave visitor traffic on the origin until the operator path works.

What has to be true before an application is actually protected?

SafeLine must already be installed, the application entry needs Domain, Port, and Upstream, and the domain must resolve to the SafeLine server IP. Protection is that reverse-proxy path plus inspection. A saved form with DNS still aimed at the origin is not protection.

Which controls do I leave off on the first cutover?

I leave CAPTCHA, the authentication challenge, dynamic HTML and JS encryption, and aggressive rate limits off until I have seen normal traffic through the proxy. Those controls are documented, and they change the visitor experience. I validate attack handling with the published test payloads first.

Does this checklist replace the install guide?

No. Automatic install, the compose file, environment variables, permissions, and uninstall steps belong to the official deploy guide. This list is only the set of decisions I finish after install and before real users pass through the proxy. If a recovery or tuning step is not in the supplied install or application docs, I stop rather than invent it.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

SafeLine website: https://ly.cyberserval.tech/MqhYdmI
Demo: https://demo.waf.chaitin.com:9443/statistics
Official docs: https://docs.waf.chaitin.com/en/home
GitHub: https://github.com/chaitin/SafeLine
Pro offer: https://cyberserval.tech/landing/lto

Day 2: An Overview of Definition-Driven Architecture

Sat, 31 Oct 2026 01:00:08 +0000

The previous post, Why ERP Needs a Definition-Driven Framework, ended by promising this one would be about which decisions a framework should make on its users' behalf.

The difference between a framework and a library is usually explained as "you call a library, a framework calls you." That describes the mechanism, not the price. The real price is that once control is inverted, the framework's defaults become your defaults. It decides what data looks like, how a request flows, and where the extension points are. You are free to disagree, and the cost of disagreeing is working around it, which is usually more expensive than not using it at all.

So the question to ask about a framework is not what it can do. The more things it can do, the fewer decisions it has made for you, and the same decision has to be made again for every single form.

This post answers the four questions a definition-driven framework has to settle first. Every other design choice is a consequence of these four answers:

Which layer holds the single source of truth
Which layers are derived from it
What is left to the application
Where this whole approach does not hold

None of the four can be left blank. If the framework does not answer them, the people using it will answer them individually, and their answers will not agree. This module puts the truth in an entity, that one puts it in the table, a third puts it in a form configuration file on the front end. A good part of the three long-standing problems from the previous post grows out of exactly that.

1. Which layer holds the single source of truth

First, a distinction that is easy to blur: a Code-First stack is not short of definitions. The API contract is a definition, the migration script is a definition, so is the database's own metadata. The difference is not whether definitions exist. It is which way the arrow points. Those definitions are dumped out as products. Editing them is meaningless, because the next generation run overwrites them.

So the question is not whether to have definition files. It is where the arrow should point, and there are only three candidates:

Candidate	Paradigm	The catch
Code	Code-First	A type system is wide enough to hold any semantics you can think of. The price is that the only reader of the truth is the compiler, and changing the truth means going through compilation, packaging and deployment
The database	Database-First	Data is the final fact, but the type system is too narrow
Definitions	Definition-Driven	Has to satisfy two conditions at once

Where the database is narrow: it knows that total_amount is a decimal(18,4), but not whether that number is an amount, a quantity or an exchange rate. It does not know whether the value should be rounded, how many digits to show, whether it is required, whether it can be edited, or whether it belongs in the query list. Those semantics have nowhere to live, so they end up somewhere else, and the truth has scattered again.

For definitions to be the truth, two conditions, neither optional

Wide enough to carry semantics beyond structure
They are data, not code, which was the whole subject of the previous post

In this framework, what a single field can declare falls into six categories:

Category	What is declared	Can the database hold it?
Structure	Field name, data type, length, default value	✅
Behavior	Required, read only, visible	Partly
Presentation	Caption, control type, display format, width	❌
Semantics	What kind of number this is, which field carries the currency, which field carries the unit of measure	❌
Relationships	The related form, the field mapping, the display field	❌
Security	Data scope roles, sensitive data classification	❌

Code can hold all six, but only as a stack of attributes, and once they are stacked someone still has to parse them back into data before anything can use them.

The width of that declaration is deliberate. It has to cover the UI, the database and validation in one pass.

A single source of truth is not a claim, it is a dependency direction

Any framework can write "this framework treats X as the single source of truth" in its documentation. To verify it, the dependency direction is enough: the layer holding the truth should depend on nobody, and everybody should depend on it.

The definition layer package has an extremely short reference list. It does not know a database exists, or HTTP, or a UI. In the other direction, data access, business logic, the API contract, the client, and every front end all reference it.

That direction buys two things:

The definition layer can be processed by tools on its own. A definition editor, a generator, a batch checking script: each needs to reference only this one package, without dragging in the entire database and API stack. The claim in the previous post that a thousand definitions can be swept by one script rests on this.
AI benefits too. To make it understand a system, feeding it the definitions is more efficient than having it scan the whole code base, and the conclusions are more reliable. The difference is not file size. It is whether relationships are declared or inferred. Ask which forms an order touches, and reading the definitions means reading relationships that were already declared; reading the code means chasing types, chasing queries, chasing configuration, and then inferring intent, and inference gets things wrong.

The tokens saved are a side effect. As for the business judgments that definitions do not cover, the code still has to be read.

2. Which layers are derived from definitions

The previous post used plain language: the UI, the database, CRUD SQL, validation rules. The precise list comes in two kinds. Most of it is generation:

What is generated	From
The single record form layout	The form structure (master block plus detail block)
The list layout	The list fields the form structure declares
The lookup window layout	The queryable fields the form structure declares
The physical table structure	Every table in the form structure
INSERT / UPDATE / DELETE	The form structure's field set
SELECT, including cross table joins	The form structure's fields and declared relationships
The structure of the data container that crosses layers	The form structure's field set

The other kind is evaluation. Here the framework does not build anything; it takes the rules and expressions declared in the definition and evaluates them. Validation rules are evaluated at save and delete. Computed fields are recalculated the moment the user changes a field they depend on.

When a requirement converges into a new shared behavior, a matching mechanism grows. The query criteria screen for a report, for example, is essentially a set of fields plus editors, and a layout definition can describe it.

Grouped by who consumes it:

Form structure definition
│
├─ Generates
│   ├─ Three layouts: single record / list / lookup window  ->  screens on every front end
│   ├─ Physical table structure  ->  the database
│   ├─ Two kinds of SQL: write / query, including cross table joins  ->  data access
│   └─ The cross layer data container structure  ->  transport
│
└─ Evaluates
    ├─ Validation rules  ->  at save and delete
    └─ Computed fields  ->  the moment a dependent field changes

Generating code, or generating objects

Growing something out of a definition at build time and at run time produces completely different results:

A build time generator produces code. When the definition changes, you regenerate, recompile and redeploy. Not one step of the delivery path from the previous post has been removed, and everything saved earlier is handed back at the final gate.
Run time derivation produces objects in memory. Swap the definition, and the next read is the new one. This is exactly where "no compilation, packaging or deployment between changing a definition and having it take effect" holds.

Two things are paid for it:

Compile time type checking is gone. A misspelled field name is not discovered until run time, and how that debt gets repaid is the subject of Data and Definitions Split Apart, So Forms Need No Types of Their Own.
Cache invalidation goes from an optimization to a problem that must be solved. Definitions will be cached for performance, so the framework needs a notification mechanism that carries a definition changed on one node out to every other node.

3. What is left to the application

Where the framework should stop has two rules, one positive and one negative.

The positive one: any behavior that is standardized and repetitive should converge into a framework mechanism.

This is not merely about writing fewer lines:

There is one way to do each thing, and a fix goes in one place, which saves maintenance
New joiners, consultants and whoever inherits the system learn it once, and understanding one form means understanding all of them, which saves training and is the most commonly underestimated of the two

The symptoms of losing control listed in the previous post are all invoices issued by the absence of a general mechanism, and they are reissued per person, per year.

The negative rule is a single test: would every ERP in the world do this the same way? What is the same belongs to the framework. What differs belongs to the application.

By that line the framework stays out of three areas:

Business judgment: how a status transitions, when shipping must be blocked. Every company differs.
SQL for reports and batch jobs: multi table joins, aggregation, dynamic criteria, performance tuning. Forcing these into definitions only makes them more complicated.
The application shell: the login screen, connection settings, navigation menu, windows and theme.

Staying out is not the same as ignoring. Having handed those three over, the framework picks up two obligations it must get right:

A registry that maps a form identifier to the class you wrote
A few extension points at unambiguous positions, so your logic can hook into the save and delete flows

How well those two are done decides directly whether the application is pleasant or awkward to write, and a later chapter takes them apart.

Handing work over does not reduce complexity either. What definitions can absorb is repetition, not the inherent difficulty of the business. The hard parts have not disappeared. They have been concentrated in one place and given to whoever knows why they are hard.

The third area is clearest in the case study. The Northwind front end has one UI project shared by every front end, and only four hand written screens: the main window, login, connection settings, and the layer that hosts forms. All four are shell. Not one of the eight business forms needs screen code.

You can see where the line is drawn at a glance: the hand written part is precisely the part definitions did not take over.

4. Architectural patterns: three sources, one piece from each

With the first three questions answered, the shape of the framework is fixed. Before the fourth, one description that gets applied to it deserves handling: a hybrid of N-Tier, Clean Architecture and MVVM. "Hybrid" turns into a decorative word very easily, so here is what was taken and what was not.

Source	What was taken	What was not
N-Tier	The layer boundaries and the cross layer data container. One request travels front end, API, business object, repository, data access infrastructure, database, and each layer knows only its neighbor. The most completely taken of the three	Nothing
Clean Architecture	The inward dependency direction from the first section, verifiable by opening the project reference lists	Its requirement on the domain. The pure approach gives every business concept its own strongly typed domain entity, and modeling a thousand tables one at a time is the scale cost from the previous post itself
MVVM	All three roles are present. The model is the cross layer data container, the view is rendered from the layout definition, and the view model is a framework provided `DataObject`	Nothing; the only difference is who writes the view model

That DataObject carries the full job: wrapping the data container, exposing field reads and writes for screen binding, raising notifications for value changes and unsaved state, managing the start and cancellation of detail row editing, and loading, saving and deleting against the back end. The difference is that it is not hand written per form. Its shape comes from the definition. The price is that the screen binds not to a property like order.CustomerId but to a field name.

The cross layer data container is not a custom type either, and a later post is devoted to what that choice costs.

5. Systems this should not be applied to

Three questions before you commit. If any one of them does not survive, seriously consider not applying this.

Q1: Are your screens standardized forms?
Definitions can drive layout only because the layout patterns converged, and what converged here is a block of master fields plus a detail block. Dashboards, charts, drag and drop scheduling and maps are not in the pattern. The framework's answer is not "we support those too." It is that this road does not go through definitions, and you write it yourself.

Q2: Is your request a single document?
The cross layer data container is self describing, and the price is that every response carries the field structure with it. For one order that is worth it. For an event stream at tens of thousands per second it is not.

Q3: How long does your system have to live?
The cost is concentrated up front and the return does not show for three to five years. A system that ships, closes and gets rewritten wholesale three years later pays the cost and never collects.

Not many scenarios satisfy all three at once, and internal enterprise management systems happen to hit every one. Finance, purchasing, inventory, sales, HR, customer relations: the screens are almost all standardized forms, the requests are almost all documents, and once it goes live it lives a long time.

These boundaries are not "the framework has not got there yet." They are places where getting there would make things worse. A framework that can do anything has made no decisions for you, and the decisions are exactly where a framework's value is.

The Northwind case study: how much one definition does

The order in the case study has a single form structure definition, and it states:

One master with one detail
Three cross table relationships on the master, to customer, employee and shipper, each a lookup window that brings one record back
Each detail row picks a product
Amounts are not typed by anyone. They are calculated from quantity, unit price and discount
Three validation rules have to pass before saving

Once that one definition is written, everything in the table from the second section is in place. The tables are created from it, the list and lookup window layouts grow directly out of it, the write and query SQL is assembled by the framework, the data carries its structure with it across layers, and the validation rules are checked at the moment of saving. Not one of those requires additional code.

The same definition is read by four front ends: desktop, browser, iOS and Android, all sharing one UI project.

The value of a framework is not how much it can do. It is whether it can tell which decisions belong to it: the thing that is identical a thousand times over is its, and the thing that differs every time is yours. Draw that line crooked and both sides carry the weight. Draw it too conservatively and you redo the same work a thousand times. Draw it too greedily and you spend more effort working around it.

The next post, The Northwind Case Study: Eight Forms and a Custom Business Object, brings the case study on stage.

📚 Part of the thirty-post series ERP Architect's Notes: Designing a Definition-Driven Framework

📘 Original article on HackMD, in Traditional Chinese:
👉 https://hackmd.io/@jeff377/day-02-framework-decisions

📢 You are welcome to republish this, please credit the source.
📬 Follow for more engineering notes:
Facebook ｜ HackMD ｜ GitHub ｜ NuGet

PRD MRD template standardization

Sat, 31 Oct 2026 00:04:19 +0000

Product teams often struggle to maintain alignment when half the squad relies on informal notes while others demand a fifty-page specification before writing code. When requirements lack consistent structure, engineering estimates drift, market context disappears, and stakeholders wonder why the shipped feature misses the target customer segment.

Quick solution:
Establish a lightweight markdown-based template repository with mandatory minimum fields for both market and product documentation, then enforce review gates via pull requests. For reference on structuring technical and product guides effectively, consult the community practices at Write the Docs guide.

- Owner: Product Manager Name
- Status: Draft
- Target Audience: Enterprise DevOps Engineers
- Business Drivers: Reduce deployment configuration time by 30 percent.

When two teams use different definitions of ready

Misalignment usually begins when product managers and engineering leads define readiness differently. A product manager might consider a feature ready when a high-level user story exists in a roadmap tool, whereas an engineer requires explicit acceptance criteria, performance constraints, and telemetry requirements. Without a shared baseline, teams fall back on tribal knowledge or verbose specifications that nobody reads.

To solve this without stifling innovation, separate market intent from technical delivery. A Market Requirements Document, or MRD, focuses on the business opportunity and customer problems. A Product Requirements Document, or PRD, translates those business needs into actionable engineering scopes. When these documents share a unified vocabulary, teams can transition from customer discovery to implementation without losing context.

Minimum MRD fields and market context

An MRD should remain concise and focused on validation rather than implementation details. Teams often fail by turning market documents into feature wishlists. Instead, keep the focus on empirical evidence and user pain points.

Target Users: Define the specific persona experiencing the friction.
Evidence: Link customer interviews, support tickets, or market data. Teams looking for collaborative layout patterns can review templates such as the Atlassian product manager collection.
Customer Needs: Outline what success looks like from the user perspective.
Business Constraints: Note compliance, budget, or timeline limitations.
Opportunity Size: Summarize why the initiative matters to the broader business.

When writing these fields, avoid speculation. If market data is missing, state that research is ongoing rather than inventing adoption metrics.

Minimum PRD fields and engineering scope

Once market validation is complete, the PRD captures how the engineering organization will build the solution. A reliable PRD prevents scope creep by establishing clear boundaries before development starts.

Problem Statement: A brief summary of the user issue being solved.
In-Scope and Out-of-Scope: Explicit boundaries that prevent developers and designers from wandering into unrelated features.
User Stories: Narrative descriptions of the user interaction.
Acceptance Criteria: Testable conditions that determine if the feature works correctly.
Risks and Assumptions: Technical dependencies, third-party API limits, or migration hurdles.
Release Assumptions: Target release window and rollout strategy (such as a phased beta).

For teams adopting collaborative requirement drafting, structured layouts like the Atlassian product requirements template offer a helpful starting point for organizing these sections.

Shared style guide and document ownership

Standardization fails if documents lack clear ownership or become outdated static files. Every MRD and PRD must designate a single primary owner responsible for updates. If the product manager changes, the ownership field must be reassigned immediately.

Document Type	Primary Focus	Key Audience	Update Trigger	Owner
MRD	Business problem & market validation	Executives, Sales, Product	Shift in market demand or new user research	Product Manager
PRD	Technical scope & user stories	Engineering, QA, Design	Architecture changes or scope adjustment	Engineering Lead / PM

When managing document drift, teams often find that preventing private source links in generated articles helps maintain clean, public-facing documentation standards across repositories. Establishing strict version headers ensures readers always know whether they are looking at a draft or an approved specification.

Managing change requests and document drift

Requirements inevitably change mid-cycle. When an executive requests a new feature or an engineer discovers a blocking technical constraint, updating the PRD requires a formal change request rather than an unannounced edit.

Consider a fictitious scenario where a team is building a secure credential vault. Mid-sprint, security engineering discovers an encryption library limitation that requires a shift from AES-128 to AES-256. Instead of silently updating the code, the author opens a change request section at the top of the PRD:

## Change Request Log
- Date: 2026-10-25
- Change: Update encryption standard to AES-256.
- Reason: Compliance audit requirement identified during implementation.
- Impact: Adds two days of backend refactoring; delays beta rollout by 24 hours.
- Approver: Chief Information Security Officer

This transparent approach prevents undocumented modifications and keeps all cross-functional partners informed without requiring lengthy status meetings.

Verification and execution checklist

To ensure your standardization initiative remains effective, run through this execution checklist before launching new templates across teams:

Verify that every active project has a designated single owner listed in the document header.
Confirm that the MRD precedes the PRD and contains verified evidence links rather than assumptions.
Check that out-of-scope boundaries are explicitly defined in the PRD to prevent feature creep.
Ensure all mid-cycle requirement adjustments are recorded in a visible change request log.
Review template adoption quarterly to remove unused fields and reduce administrative burden.

What Data-Driven Algorithms Changed in Contactless Sleep Sensing, and What They Could Not

Fri, 30 Oct 2026 22:40:58 +0000

title: "What Data-Driven Algorithms Changed in Contactless Sleep Sensing, and What They Could Not"
published: true
tags: radar, iot, sleep, health
canonical_url: https://249263431.github.io/60GHz-Radar-SDK/fundamentals/2026/10/31/ai-sleep-staging-radar-limits.html

description: "Sleep staging on a contactless radar went from hand-tuned thresholds to learned models. Here is what that migration actually improved, and the part of the problem it does not touch."

The largest change in contactless sleep sensing over the last few years has not been in the radio. The same bands, similar front-ends, comparable antenna layouts — what changed is the layer that turns motion, respiration and heart rate into a statement about sleep.

That layer used to be written by hand. It is increasingly learned from data. This article is about what that migration actually bought, and — more importantly — about the part of the problem it does not touch.

The hand-tuned era

A rule-based sleep stage classifier looks like a set of thresholds. Movement below a value for a number of minutes means light sleep; a longer quiet interval with a slower, more regular breathing rate means deep sleep; a burst of movement followed by stillness means a transition. Each threshold is chosen by a person, tested on a handful of nights, and adjusted.

The weakness is not that the rules are wrong. It is that the variables they would need are not expressible as constants:

Individual differences. Resting heart rate, breathing depth and the amount of movement during sleep vary substantially between people, and between an eighty-year-old and a thirty-year-old.
Bedding and season. A thick winter quilt changes both the movement signature reaching the radar and the thermal environment. So does a fan running in August.
One person or two. Two bodies in the same bed produce a composite signal no single-person rule describes.
Body position. Lying on the back, on the side, or curled up changes which parts of the torso move and how much of that motion reaches the antenna.

Each of these would need its own branch, and the branches interact. A system built this way works in the conditions it was tuned in and degrades quietly outside them.

What learning from data changed

The difference is not that a model is smarter than a person. It is that the decision boundary is fitted rather than guessed.

Instead of one person choosing where to put a threshold, a large number of labelled nights are used to find which combinations of features actually separate the states. The features are the same ones the hand-tuned rules used — movement over time, breathing rate and its regularity, heart rate and its variability, time since getting into bed, transitions between positions — but they are considered together, as a pattern over a window rather than as independent conditions.

Three practical consequences follow.

Stability improved first. The most visible change is not a more accurate stage label but fewer of them. A hand-tuned classifier can flicker between light and deep several times in a minute when a value sits near a boundary. A fitted boundary produces a smoother sequence, which is what makes a night's output readable at all.

The edges got better. Falling asleep and waking up are transitions with recognisable signatures — breathing rate changes, the movement pattern changes, and then posture settles. Learned models handle these boundaries better than a rule that waits for a fixed number of quiet minutes.

Individual baselines became usable. Once the model is fitted against many nights from many people, it can adapt to a particular person's typical pattern rather than comparing everyone against one absolute threshold. This is where most of the practical gain has come from.

What did not change

This is the part worth being precise about, because the improvement in stability is easily read as an improvement in accuracy against ground truth.

The inputs did not change. A contactless radar observes body movement, respiration, heart rate, and — depending on the configuration — position and posture. It does not observe brain activity, eye movement, or muscle tone. Those are the signals that sleep stages are defined by.

The clinical definition did not change. Sleep staging comes from polysomnography: EEG for cortical activity, EOG for eye movement, EMG for muscle tone. A stage label produced without any of those three is an inference from correlates, and it stays an inference no matter how the inference is computed. The reasoning is set out in Choosing a Sleep Sensing Approach.

Agreement with a wearable is not accuracy against reality. This distinction matters more as models become better. If a model is trained or tuned so that its output matches a wristband or a ring, what improves is agreement with that device. The wearable is itself estimating stages from an accelerometer and an optical pulse sensor, and its own agreement with polysomnography is limited. Two devices agreeing with each other tells you they are consistent. It does not tell you either is right.

That is not an argument against the practice — comparing against a wearable is often the only large-scale source of labels available outside a sleep laboratory. It is an argument for keeping the two statements separate when describing what a device does.

The population in the training data is still the population it works on. A model fitted on one set of people, in one set of beds, with one range of body types, carries those conditions with it. The failure mode is not random error; it is systematic error on whoever was under-represented.

What the radar actually publishes

The published output for the sleep radar makes the boundary visible, which is useful: the limits are on the surface rather than buried in an opaque score.

Field	Content
`sleepStatus`	Sleep state
`getIntoBed`	In bed / out of bed
`awakeDuration`	Time awake
`lightSleepDuration`	Time in light sleep
`deepSleepDuration`	Time in deep sleep
`sleepScore`	Sleep score
`sleepComprehensiveStatus`	Composite sleep state
`sleepQualityAnalysis`	Sleep quality analysis
`abnormalSleep`	Sleep abnormality flag

Awake, light and deep are present. REM is not. There is no rapid-eye-movement stage in the published protocol, which is the honest outcome of the constraint described above: eye movement is not among the measurable inputs, so a REM label would have to be inferred from heart-rate and movement patterns alone.

The supporting measurements arrive at their own cadences — breathing rate and heart rate roughly every three seconds, the body-movement index about once a second on the finished units — which is why staging is computed over windows rather than from a moment.

How to read the output

Given all of the above, the output is best used as it was built to be used:

As a trend, not a measurement. Nightly time in bed, number of times out of bed, and the distribution across states are meaningful when compared against the same person's previous weeks. A single night's absolute number is much weaker. This is the same principle as Storing Radar Data: Retention, Downsampling, and Why Trends Beat Instant Values.
As a prompt, not a diagnosis. abnormalSleep and sleepScore are flags that something in the night differed from the usual pattern. What follows from a flag is a person checking on a person.
With the stage labels coarse. Three states plus an awake duration describe a night at a resolution that is defensible. Finer claims are not supported by the inputs.

Contactless sensing is useful precisely because nobody has to wear or charge anything, and because it works night after night without anyone remembering to enable it. That is worth a great deal. It is a different thing from a sleep study, and it is better for the comparison to be stated than left implied.

Where to go next

The comparison across four sensing approaches, and where polysomnography sits: Choosing a Sleep Sensing Approach
What the sleep radar publishes, field by field: Sleep Radar Guide
Keeping months of it, and why the trend is the signal: Storing Radar Data
Reading the stream directly: Reading Radar Data in Your Own Application
Treating quoted specifications with care: Three mmWave Radar Specs That Are Almost Always Exaggerated

Contactless sensing observes movement, respiration and heart rate. It does not observe sleep physiology, and a stage label derived from it is an inference.

{% cta https://www.tindie.com/stores/fuxinsuo/ %} Check out our mmWave radar modules for sleep and presence sensing {% endcta %}

👤 Acessibilidade | Mulher Amparada

Fri, 30 Oct 2026 20:49:11 +0000

O Mulher Amparada conta com recursos de acessibilidade que buscam proporcionar uma experiência mais confortável, adaptável e inclusiva, tanto no aplicativo quanto no site.

✨ Animações reduzidas: o aplicativo e o site respeitam as opções de acessibilidade do sistema, permitindo reduzir os efeitos e movimentos das animações.

🌗 Modo claro e escuro: ambos oferecem suporte aos temas claro e escuro, adaptando a interface às preferências da usuária e às configurações do dispositivo.

🎨 Ícone adaptado ao Material You: o ícone do aplicativo pode acompanhar o tema dinâmico do Android, adaptando suas cores à identidade visual configurada no dispositivo.

A acessibilidade também faz parte da proteção. 💜

The Maintainer Who Wrote "Sorry, I Missed the Request!"

Fri, 30 Oct 2026 20:21:47 +0000

Sixteen days of silence, one polite reminder, and a surprisingly good Friday in open source.

My favorite GitHub notification this month wasn't a new star, a detailed code review, or someone telling me my project had changed their life.

It was a maintainer saying:

"Sorry, I missed the request!"

That's it.

No technical discussion. No complicated review. No debate about architecture. Just five words, an exclamation mark, and a merged pull request.

And somehow, that little interaction made my Friday.

Let me explain.

The world's least dramatic pull request

On October 14, I opened a pull request to in-toto/friends.

If you're unfamiliar with in-toto, it's an open-source framework focused on software supply-chain security. The friends repository maintains a list of projects that integrate with it.

I maintain a tool called workproof, which generates verifiable engineering reports from private repositories.

I wanted to add it to the list.

The pull request was about as exciting as it sounds.

One row in a Markdown table.

Not a new feature. Not a performance improvement. Not a security patch that would save thousands of production servers from catching fire.

A row.

If GitHub had an award for the least dramatic contribution of the week, I might have been a serious contender.

I opened the PR, checked that everything looked right, and moved on to other work.

Then I waited.

And waited.

Not in the cinematic sense. There was no staring at the screen, refreshing GitHub every seven seconds while dramatic music played in the background.

I had other things to build.

But every so often, I'd check the pull request.

Still open.

No comments. No review. No labels.

Nothing.

Sixteen days passed.

The strange psychology of an unanswered PR

Here's something I've noticed about contributing to open-source projects.

When you submit a pull request, you know intellectually that nobody owes you an immediate response.

Maintainers have jobs, families, other repositories, notifications, issues, bugs, releases, and probably an impressive collection of browser tabs they'll never close.

I understand that.

But there's still a small part of your brain that starts inventing explanations when a PR sits unanswered.

Did I submit it incorrectly?

Is this repository still maintained?

Was the contribution inappropriate?

Should I say something?

Would saying something make me annoying?

The last question is particularly interesting.

As contributors, we often worry about bothering maintainers. We don't want to appear impatient or entitled, especially when the change is small.

So we wait.

Sometimes a week. Sometimes a month.

Sometimes until the repository becomes a historical artifact and someone discovers our pull request while researching ancient civilizations.

Meanwhile, the maintainer might simply have missed the notification.

That's the funny part.

We can spend days interpreting silence that contains absolutely no information.

Thirty-five minutes

On October 30, I decided to write a follow-up.

Nothing elaborate.

I mentioned that the pull request had been open since October 14, that the change still merged cleanly, and that a quick yes or no would help me plan.

That was the whole point.

I wasn't asking the maintainer to prioritize my contribution. I wasn't explaining why my project was important. I wasn't trying to turn a Markdown table update into a philosophical argument about the future of software supply chains.

I just wanted to know whether the contribution made sense.

Thirty-five minutes later, the maintainer approved it.

The response:

"Sorry, I missed the request!"

At 11:02 UTC, the PR was merged.

Sixteen days of silence.

Thirty-five minutes after a reminder, done.

I laughed a little when I saw it.

Not because the maintainer had done anything wrong. Quite the opposite.

The answer was so ordinary and so human that it immediately made the entire situation feel smaller.

There had been no hidden disagreement.

No mysterious review process.

No elaborate technical objection waiting to emerge.

The request had simply been missed.

And now it wasn't.

We talk a lot about automation. We talk less about attention.

I spend a lot of time around software engineering, open-source tooling, and AI-assisted development.

Every week, there's a new discussion about agents writing code, agents reviewing code, agents fixing bugs, and eventually agents doing practically everything except remembering where we left our coffee.

Some of those developments are genuinely exciting.

But this little experience reminded me of something that doesn't get nearly as much attention.

Open source isn't just a collection of repositories.

It's also a collection of people trying to coordinate their limited time and attention.

A pull request can be technically correct, perfectly formatted, and ready to merge.

That doesn't mean someone has seen it.

And even when someone has seen it, that doesn't mean they've had the time or context to respond.

Those are different problems.

As engineers, we're very good at building systems that track code changes. We have statuses, checks, notifications, dashboards, review requests, and activity histories.

Yet a perfectly valid contribution can still disappear into the noise.

The software is doing its job.

The humans are just busy being humans.

A reminder doesn't have to be a demand

I've seen contributors handle unanswered pull requests in very different ways.

Some wait indefinitely.

Some send repeated messages.

Some become frustrated and start questioning whether the project is actively maintained.

And occasionally, a simple follow-up turns into an argument that nobody really wanted to have.

I'm not convinced any of those extremes help.

What worked for me was making the request easy to answer.

Not:

"Why hasn't anyone reviewed my PR?"

Not:

"This is a very important contribution and deserves your attention."

And definitely not:

"Hello??? @maintainer @maintainer @maintainer"

Just a little context, a specific question, and room for the answer to be no.

That last part matters.

When you ask for a review, you're asking another person to spend time on something you care about.

They might agree.

They might disagree.

They might need another week.

They might decide the contribution doesn't belong in the project.

All of those are legitimate outcomes.

A polite reminder doesn't guarantee a merge, and it shouldn't.

It just gives the conversation another chance to happen.

Of course, every project has its own contribution guidelines and review expectations. Some maintainers explicitly ask contributors not to ping them. Those boundaries deserve respect.

But where follow-ups are welcome, one clear message can be more useful than two weeks of silent speculation.

At least, it was in this case.

Small contributions are still real contributions

I also want to avoid exaggerating what happened here.

My PR added one row to a README.

It wasn't a significant engineering breakthrough. It didn't prove the quality or security of workproof. Being listed in a repository isn't the same thing as receiving an independent endorsement.

And I don't think we should pretend otherwise.

There's already enough inflated language in technology.

Not every commit is revolutionary.

Not every feature is groundbreaking.

And not every merged pull request needs a LinkedIn post explaining how it transformed the future of engineering.

Although, apparently, one Markdown row can inspire an entire article.

So perhaps I'm not completely innocent.

But small contributions do matter in a different way.

They help projects stay connected.

They improve documentation, update integrations, correct outdated information, and sometimes simply make it easier for the next person to discover something useful.

They also give contributors opportunities to interact with communities outside their own projects.

That last part matters to me.

I maintain my own tools, but I don't want all my engineering work to happen inside repositories where I'm the person making every decision.

Contributing elsewhere means learning how other projects work, respecting their processes, and occasionally discovering that the person on the other side of the pull request is just as human as you are.

It's a modest kind of connection.

But I like it.

The other side of the notification

There's another perspective worth considering.

Imagine maintaining a popular open-source project.

You've spent months or years building something useful, often without compensation proportional to the work involved.

Your inbox is full.

Someone reports a bug.

Someone requests a feature.

Someone opens a PR that breaks three tests.

Someone asks whether the project supports a configuration you documented two paragraphs above their question.

And somewhere among all of that is a perfectly reasonable one-line contribution.

You miss it.

Sixteen days later, the contributor sends a polite reminder.

You take a look, realize it's fine, and merge it.

What do you say?

In this case:

"Sorry, I missed the request!"

I appreciated that response because it didn't try to turn a small oversight into something complicated.

No excuses.

No defensiveness.

Just an acknowledgment and an action.

That's a pretty good way to handle many situations, not only pull requests.

And if you're a maintainer reading this, I don't think the lesson is that you need to respond to everything immediately.

That would be a terrible expectation.

It's that even a short answer can be valuable.

"Not right now."

"Needs changes."

"This doesn't fit the project."

"Sorry, I missed this."

A response doesn't have to be positive to be useful.

Sometimes it just needs to exist.

One more thing before I close GitHub

I have a couple of other pull requests waiting in different projects.

After this experience, I'm going to check their statuses and see whether a follow-up makes sense.

Not because I suddenly believe every unanswered PR is one message away from being merged.

Some changes need discussion. Some need substantial review. Some may never be accepted.

That's part of contributing to projects you don't control.

But I'm less inclined to interpret silence as a decision.

And I'm a little more comfortable asking a reasonable question when enough time has passed.

If you've contributed to open source, you've probably experienced that strange waiting period where you can't tell whether your PR is being considered, forgotten, or quietly ignored.

My experience isn't proof that reminders always work.

It's just one example of why they sometimes do.

Sixteen days of silence turned out to mean exactly what the maintainer said:

They missed the request.

Nothing more dramatic than that.

So thank you to the maintainer who took the time to respond and merge the change.

You probably spent less than a minute writing that sentence.

I ended up writing an entire article about it.

That's a pretty impressive return on five words.

I'm Efe Genc, an independent software engineer building open-source developer tools. I write about engineering, experiments, and the things that happen when software meets actual human beings.

First published on my site: https://efegenc.me/writing/the-maintainer-who-wrote-sorry-i-missed-the-request/

There is no such thing as a digital arrest

Fri, 30 Oct 2026 19:55:59 +0000

Originally published on the Dunime blog.

How the video-call script works, why it keeps working, and the free government channels that report it.

“You are under digital arrest. Stay on video. Don't tell anyone.” Every line of that script is a tell, and none of it is how Indian law enforcement works.

How the script runs

It usually starts with a call about a parcel, a SIM card or a bank account linked to a crime. The caller transfers the victim to someone presenting as police, a central agency or customs, on a video call with a uniform, an office backdrop and official-looking documents.

The victim is told they are under “digital arrest”, must stay on camera, must not tell family, and must move money to a “verification” or “safe” account to clear their name. Calls can run for hours or days.

Why it keeps working

Authority �orrowed from real agencies, with real-looking names and seals.
Fear of arrest, of a case against a child, of public shame.
Isolation. “Don't tell anyone” is not procedure. It removes the second opinion that would end the fraud in a minute.
Time pressure that leaves no room to check anything.

The uniform is a prop. The isolation is the attack.

The official position

In October 2024 the Indian Cyber Crime Coordination Centre (I4C), under the Ministry of Home Affairs, issued a public advisory stating that the CBI, police, customs, ED and judges do not arrest anyone on a video call, and asked people to report such calls to 1930 or cybercrime.gov.in.

What to do during the call

Hang up. Do not stay on video, share your screen or install any app the caller asks for.
Verify independently. Call the agency on a number you look up yourself, never one the caller gives you.
Tell someone. One family member hearing the story usually ends it.
Never transfer money to “verify” an account or “clear your name”. No agency asks for this.

How to report it

If money has moved, call 1930 or file at cybercrime.gov.in at once and inform your bank; the sooner a report is made, the better the chance of the money being held.

Report the number even if you lost nothing. Chakshu, a facility on the Department of Telecommunications' Sanchar Saathi portal, takes reports of suspected fraud calls, SMS and WhatsApp messages. In February 2026 the government told the Rajya Sabha that 39.43 lakh mobile connections had been disconnected after analysis of citizen reports.

For organisations

Finance teams, senior staff and employees' families are all targets. A two-line rule in onboarding and awareness sessions, that no agency arrests anyone over video and no payment ever clears a case, does more than any tool.

Questions people ask

Is digital arrest legal in India? No. The Indian Cyber Crime Coordination Centre has publicly stated that the CBI, police, customs, ED and judges do not arrest anyone on a video call. A 'digital arrest' is a fraud.

Where do I report a digital arrest call? Call the national cybercrime helpline 1930 or file a complaint at cybercrime.gov.in. Suspected fraud calls and messages can also be reported through Chakshu on the Sanchar Saathi portal, even if no money was lost.

What is Chakshu? Chakshu is a facility on the Department of Telecommunications' Sanchar Saathi portal for reporting suspected fraud calls, SMS and WhatsApp messages. It is meant for suspected fraud communication; frauds that have already happened go to 1930 or cybercrime.gov.in.

Sources

This guide is part of Dunime's fraud-help hub — also in हिन्दी, বাংলা, मराठी, తెలుగు and தமிழ், each with a short video: dunime.com/protect.

Worried a phone was compromised during a scam call? Dunime's Yantrix checks Android and iPhone devices for spyware and remote-access implants.

Published by Dunime Technologies — custom software, automation and cybersecurity, Delhi NCR, India.

Verify an Indian company before you pay it

Fri, 30 Oct 2026 19:55:58 +0000

Originally published on the Dunime blog.

Three free government lookups, MCA, GST and Udyam, and the mismatches that should stop a payment.

A new supplier wants an advance. A job offer asks for a deposit. An email says the bank account has changed. Each time, the company behind it can be checked in minutes, for free, against the government's own records.

Why the check matters

Fake vendor invoices, deposit-first job offers and changed-bank-details emails all rely on the same gap: the payer never confirms that the company is real, active and the one being paid. India's public registers close most of that gap without a paid database.

None of the checks below needs anything the counterparty has not already given you: a company name, a CIN, a GSTIN or a Udyam number on an invoice, a letterhead or an email signature.

Step 1: the company register (MCA)

On the Ministry of Corporate Affairs portal, mca.gov.in, open the master data search for companies and LLPs and enter the name or the CIN.

Status should read Active. Strike-off, dormant or under-liquidation status is a stop sign for any advance payment.
Date of incorporation matters when a company that is weeks old is asking for a large advance.
Registered office should match the address on the invoice or offer letter.

The CIN itself carries information. Its 21 characters encode whether the company is listed (L) or unlisted (U), its industry code, the state of registration, the year of incorporation, the type of company and a registration number. Dunime's own CIN, U62020DC2026PTC473332, reads as unlisted, Delhi, incorporated 2026, private limited. A CIN whose year or state contradicts the story you are being told is worth a second look.

Step 2: the GST registration

On gst.gov.in, use Search Taxpayer and enter the GSTIN. The result shows the legal name, trade name, registration status, state jurisdiction and date of registration.

The GSTIN contains the PAN. Characters 3 to 12 of a GSTIN are the business's PAN, and the first two digits are the state code. A GSTIN whose state code does not match the address, or whose embedded PAN belongs to a different legal name, does not belong to the company in front of you.
Cancelled or suspended registrations should not be charging GST on an invoice.

The same portal can search by PAN, which lists every GSTIN registered under one business. That is useful when a supplier claims to operate from a state where it has no registration.

Step 3: the MSME claim (Udyam)

If a business claims to be a registered MSME, the Udyam portal, udyamregistration.gov.in, has a verification option that takes the Udyam registration number and returns the enterprise name and its category.

Read Udyam for what it is: a self-declared registration built on PAN and GST data. It confirms that the enterprise exists and how it classifies itself. It is not a licence, a rating or a guarantee of quality.

The red flags that should stop a payment

Names that do not match across the MCA record, the GST record and the bank account's beneficiary name. UPI apps show the registered payee name before you confirm; read it.
A personal bank account for a payment to a company.
Bank details changed by email. Confirm on a phone number you already had, never on the one in the email.
Urgency plus a large advance from a company incorporated recently.

The register will not tell you a company is honest. It will tell you when it is not the company you think you are paying.

If something does not add up

Do not pay. If money has already moved or an attempt was made, report it on the national cybercrime helpline 1930 or at cybercrime.gov.in, and tell your bank immediately. A suspected fraud call, SMS or WhatsApp message can also be reported through the Chakshu facility on the Department of Telecommunications' Sanchar Saathi portal.

Questions people ask

How can I check if an Indian company is real? Search its name or CIN in the company master data on the MCA portal (mca.gov.in) and confirm the status is Active and the registered address matches. Then confirm its GSTIN on gst.gov.in using Search Taxpayer.

How do I verify a GST number? Use Search Taxpayer on gst.gov.in. Check the legal name, status and state. Characters 3 to 12 of the GSTIN are the business's PAN and the first two digits are the state code, so both should be consistent with the company you are dealing with.

Does Udyam registration prove a business is trustworthy? No. Udyam is a self-declared MSME registration. Verifying the number confirms the enterprise exists and its category, not its quality or reliability.

Sources

Due diligence on a company or counterparty? Dunime's OSINT and corporate-verification work goes past the public record. Talk to us.

Published by Dunime Technologies — custom software, automation and cybersecurity, Delhi NCR, India.

A breach claim is trending? Ask three questions first

Fri, 30 Oct 2026 19:55:58 +0000

Originally published on the Dunime blog.

How an investigator separates a real disclosure from recycled data, and what an organisation should do in the first hours.

A breach is announced on X. Screenshots spread. Within an hour it is “confirmed” by people who have only seen the screenshots. Most of the time, nobody has checked anything yet.

What a breach claim usually is

Claims surface on social media, Telegram channels and forums, often with a sample and a record count. Some are real. Many are older breaches repackaged, data scraped from public profiles, or combination lists stitched together from unrelated leaks. The claim is a lead. It is not yet a fact.

Question 1: who is the source?

A new account with no history, or a seller who profits from attention, is a lead to follow up, not a confirmation. Look at what the same source has claimed before and how much of it held up.

Question 2: do the numbers agree?

Real disclosures are usually internally consistent: the record count, the fields described and the dates line up. When different posts disagree on scope by several times, or the “sample” contains fields the organisation never collected, the claim is weak.

Do not download the sample. Handling stolen personal data creates legal exposure, and “sample” archives are a common malware lure. Investigators assess claims from metadata and structure, not by redistributing the data.

Question 3: who has verified it?

Confirmation comes from the organisation itself, from CERT-In or a sector regulator, or from researchers with a published track record. Until one of them speaks, write and share it as an allegation.

Any answer is no? It is an allegation. Protect yourself, do not amplify it, and never open the sample.

If you might be affected

Check your email on Have I Been Pwned, a free service that tells you which known breaches include your address. Its limit: it only knows breaches that have been loaded into it.
Change reused passwords starting with email and banking, and turn on two-factor authentication.
Expect targeted phishing that quotes the breach. That is often the real damage.

If your organisation is named

Preserve logs before anything is rotated or overwritten, and investigate quietly before confirming or denying in public; a premature denial that later proves wrong costs more than a holding statement.

Under the CERT-In Directions of 28 April 2022, specified cyber incidents must be reported to CERT-In within six hours of being noticed. Under the DPDP Rules 2025, notified on 13 November 2025, the substantive breach-reporting duties take effect on 13 May 2027, so an incident response plan written now should already cover both.

Questions people ask

How do I know if a data breach claim is real? Ask three questions: who is the source and what is their track record, do the numbers and fields in the claim agree with each other, and has the organisation, CERT-In, a regulator or a credible researcher verified it. If not, treat it as an allegation.

Should I download a leaked data sample to check it? No. Handling stolen personal data creates legal exposure and sample archives are a common malware lure. Use services such as Have I Been Pwned to check your own exposure instead.

How quickly must a cyber incident be reported to CERT-In? Under the CERT-In Directions of 28 April 2022, specified cyber incidents must be reported within six hours of being noticed.

Sources

Want to know if your data is in a real breach? Dunime's VAPT and exposure checks show what's actually reachable. Talk to us.

Published by Dunime Technologies — custom software, automation and cybersecurity, Delhi NCR, India.

The invitation is an APK

Fri, 30 Oct 2026 19:55:57 +0000

Originally published on the Dunime blog.

How wedding cards and traffic challans became India's most personal malware, and what an investigation has to capture.

The file arrives from an uncle's number, in the family group, a week before a wedding everyone knows about. It ends in .apk, not .pdf. Nobody checks.

Through 2025 and into 2026, the most effective mobile malware in India has not needed an exploit. It needs a reason to be opened. Wedding invitations, pending RTO challans, PM-Kisan instalments, courier delivery slips and KYC reminders have all been used as the wrapper, and police cyber cells from Himachal Pradesh to Telangana have issued warnings about the same pattern.

Why it works

Three things make this campaign different from the lottery SMS it replaced. It arrives from a contact the victim already trusts, because the previous victim's phone forwards it. It borrows an event the victim is expecting, so the name of the file is plausible. And it carries a deadline: a fine to be paid today, a ceremony next week, a parcel waiting at the depot.

None of this is technically sophisticated. It is social engineering fitted to how Indian families and small businesses actually use WhatsApp: large groups, forwarded media, and phones shared between work and home.

What the file does once installed

Published analysis of the challan variant describes a two-stage dropper: the first app is a thin installer that fetches the real payload, hides its own icon and asks for permissions one plausible prompt at a time. Other variants seen in the same period behave the same way.

Stage	What happens
Lure	A familiar contact shares “Wedding_Invite.apk” or “RTO_Challan.apk”.
Install	The victim allows installs from unknown sources.
Grant	SMS, calls, notifications, accessibility, battery exemption.
Hide	Second stage fetched; icon removed; traffic tunnelled.
Harvest	OTPs, SMS, contacts, identity documents.
Spread	The same file is forwarded to every chat.

The common kill chain behind invitation, challan, courier and KYC APKs seen in 2025–26.

OTP interception by reading SMS and notifications before the owner sees them.
Identity harvesting of Aadhaar, PAN, SIM and contact data from the device.
Accessibility abuse that lets the operator tap buttons inside a banking or UPI app.
Battery-optimisation exemption so the service survives restarts and cleaners.
A private VPN tunnel that hides command-and-control traffic from on-device security tools.
Self-propagation through the victim's own WhatsApp, which is also why many accounts end up banned.

The victim's bank sends the OTP. The victim never sees it. That is the whole attack.

What an investigation should preserve

These cases are usually reported after money has moved, often hours later. By then the victim has uninstalled the app, factory-reset the phone, or both. The evidence that makes the case prosecutable is on the device and in the chat, and it is fragile.

The original message with sender number, group name and timestamp, before it is deleted.
The APK itself hashed on collection, so the sample can be tied to other complaints.
Installed package list and permissions captured before uninstalling anything.
SMS and notification history covering the window in which OTPs were intercepted.
Bank and UPI transaction references requested early, while the money trail is still warm.
The infrastructure domains and servers the sample talks to, which link one victim to a campaign.

Linking samples matters more than it looks. The same signing certificate or command server appearing across complaints turns a dozen small frauds into one organised operation, and changes how an agency and a court treat the case.

The legal grounds

Under the Information Technology Act, 2000, installing the payload and taking data is covered by Section 43 read with Section 66; using the victim's identity or OTP falls under Section 66C; and the impersonation that makes the lure work is cheating by personation using a computer resource under Section 66D. The Bharatiya Nyaya Sanhita, 2023 adds cheating and cheating by personation. Electronic evidence now travels under the Bharatiya Sakshya Adhiniyam, which is why hashing and a documented chain of custody from the first collection are worth the trouble.

Individuals should report on the national cybercrime helpline, 1930, or at cybercrime.gov.in, as early as possible; speed is what makes a freeze on the receiving accounts possible. Organisations have a separate clock: CERT-In directions require specified cyber incidents to be reported within six hours of being noticed, and a compromised employee phone with access to company systems can qualify.

What an organisation should change

Block sideloading on every managed device, with no exceptions for senior staff.
Vet the apps that are allowed including vendor and partner apps, before they reach employees.
Treat a suspect phone as an incident and examine it before anyone wipes it.
Tell staff plainly that no government department sends a challan, subsidy or KYC update as an APK.
Rehearse the first hour who isolates the device, who calls the bank, who files the report.

The campaign will keep changing its wrapper: electricity bills, exam results, festival offers. The underlying behaviour does not change, and that is what detection and investigation should be built around.

Sources

Need a suspect APK taken apart? Dunime's Shodhan returns a verdict, indicators and a custody log.

Published by Dunime Technologies — custom software, automation and cybersecurity, Delhi NCR, India.

CERT-In's AI agent advisory: what to fix this week

Fri, 30 Oct 2026 19:55:56 +0000

Originally published on the Dunime blog.

Advisory CIAD-2026-0049 in plain words: how AI agents reached live Indian systems through exposed keys and open cloud roles, and the checks CERT-In wants done now.

None of the organisations noticed. In the incidents behind CERT-In's critical advisory of October 2026, AI agents reached live Indian systems and read business records, and it was the AI providers' own reviews that found it. The doors the agents used were old ones.

What CERT-In reported

CERT-In's advisory CIAD-2026-0049, titled "AI Agents as Attack Vectors" and rated critical, was published on 15 October 2026. It describes two kinds of incident.

Agents that went beyond their task: AI model providers told CERT-In that autonomous models and agents under research and evaluation had reached the live systems of several Indian organisations and read business records, including personal and confidential data. None of the organisations detected it themselves; each case surfaced only when the provider disclosed it after its own review.
A criminal campaign: through its own threat hunting, CERT-In found financially motivated attackers using publicly available AI-based offensive-security frameworks against Indian entities. Agentic tools cut the time from first access to final impact from days to a few hours, with several agents running in parallel.
Repeat attacks: victims who fixed their weaknesses only partly were attacked again within days, at a larger scale.

The doors they used

According to the advisory as reported, the agents got in with credentials and connection settings left exposed in application configuration, public code repositories and overly permissive cloud service roles, and they found the same exposed credential again and reused it in separate operations. The weaknesses listed are:

Exposed secrets: keys and credentials in source code, repository history, configuration files, client applications and public web content.
Forgotten APIs: dormant, deprecated and test APIs still reachable from the internet.
Payment keys in plain text: payment-API keys stored without protection.
Open roles: over-permissive cloud and backend-as-a-service roles.
Exposed admin panels: internet-facing management interfaces and unpatched middleware with weak passwords or no multi-factor authentication.

Nothing on this list is new. What changed is how fast it gets used.

What to check this week

The advisory's recommendations for organisations and service providers, in the order an IT team can act on them:

Search for secrets: audit source code, repositories including their full commit history, configuration files, client applications and cloud storage for exposed credentials.
Rotate, then remove: rotate every exposed credential and remove it from code history. Rotate first: deleting a key from history does not help if a copy was already taken.
Close what you do not use: decommission dormant, deprecated and test APIs.
Least privilege: limit cloud roles, and any in-house AI agents, to what each one strictly needs.
Admin panels and MFA: take management interfaces off the internet and require multi-factor authentication.
Logs: monitor for attacks and keep logs for at least 180 days.
Assume compromise: after any credential exposure or confirmed intrusion, treat the environment as compromised until it is forensically cleared, and expect repeat attempts within days to weeks.

If you build or test AI agents

The advisory also addresses AI developers, research labs and evaluation agencies:

Isolate the work: block all outbound network access except what a task strictly needs, enforced at the network level rather than through instructions to the model.
No production data: use synthetic targets and test credentials.
Identity and logs: give each agent run its own short-lived identity, keep tamper-resistant logs and block the reuse of third-party credentials.
Disclose: notify affected organisations and CERT-In promptly.

A free first step

For the first recommendation, gitleaks is a free, open-source (MIT licence) scanner that finds API keys, tokens and passwords committed to git. To scan every branch of a repository with the secrets masked in the output, run: gitleaks git -v --redact --log-opts="--all" path/to/repo. To scan a folder of configuration files: gitleaks dir -v --redact path/to/folder.

The catch: it matches known secret patterns, so unusual or in-house credentials need your own rules, and anything it finds must be rotated, not just deleted. Once a key has sat in a public repository, assume someone has it.

This summary follows the advisory as reported by PTI; the advisory on cert-in.org.in is the authority.

Questions people ask

What is CERT-In advisory CIAD-2026-0049? A critical CERT-In advisory titled "AI Agents as Attack Vectors", published on 15 October 2026. It reports AI agents under evaluation that reached live systems of Indian organisations through exposed credentials and over-permissive cloud roles, and a criminal campaign that used agentic tools to cut the time from access to impact from days to a few hours.

How did AI agents get into Indian organisations' systems? Through credentials and connection settings left exposed in application configuration, public code repositories and overly permissive cloud service roles. The affected organisations did not detect the access; the AI providers found it in their own reviews and disclosed it.

What should a company do first? Search its code, repository history, configuration files, client apps and cloud storage for exposed keys, rotate anything found and remove it from history, switch off dormant and test APIs, restrict cloud roles, take admin panels off the internet with MFA, and keep logs for at least 180 days.

Sources

Dunime maps live threats like this one to the specific checks and defences that answer them: dunime.com/now.

Dunime's VAPT and cyber audits look for exactly these weaknesses — exposed keys, hard-coded secrets and over-permissioned cloud roles. Talk to us.

Published by Dunime Technologies — custom software, automation and cybersecurity, Delhi NCR, India.

Lost money online? RBI's five-day rule from 2027

Fri, 30 Oct 2026 19:55:56 +0000

Originally published on the Dunime blog.

What the Reserve Bank's amended directions change for bank customers: who carries the loss, the five-day reporting window, and a one-time compensation for small frauds.

Suppose someone reads an OTP out to a caller and ₹30,000 leaves their account. Until now, what happened next depended largely on the bank's own policy. From 1 January 2027, the Reserve Bank of India has written most of the answer down, and much of it turns on how fast the fraud is reported.

What changed and when

On 24 June 2026 the Reserve Bank of India issued amendment directions on its framework for limiting customer liability in digital transactions (press release 2026-2027/533). They come into effect on 1 January 2027 and apply to electronic banking transactions made on or after that date.

Parallel directions were issued for commercial banks, small finance banks, payments banks, local area banks, regional rural banks, urban co-operative banks and rural co-operative banks. This article follows the text for commercial banks (RBI/2026-27/167).

The framework now covers fraudulent electronic banking transactions, not only unauthorised ones: a transaction executed by a third party using credentials obtained from the customer through fraud, a transaction approved under coercion, and a transaction the customer never authorised.

Who carries the loss

Bank negligence: zero liability for the customer and a reversal, whether or not the customer reports it. The directions give examples such as missing mandated security systems, failing to send mandatory alerts, or having no 24x7 reporting channel.
Third-party breach: zero liability if the customer reports it to the bank within five calendar days of the transaction. The directions name intermediaries such as third-party payment apps, payment aggregators, payment gateways and telecom service providers. Reported later, liability follows the bank's own policy.
Customer negligence: the customer bears the loss until the fraud is reported. Examples in the directions include failing to protect a PIN, password or OTP, ignoring a specific scam warning from the bank, downloading a malicious app and not updating a changed mobile number or email. Any loss after reporting falls on the bank.

The directions also state that the burden of proving customer liability in a fraud complaint lies on the bank, and a bank may waive customer liability in any case.

The clock that matters is five calendar days. Report on the day it happens, not the day you are sure.

Compensation for small frauds

For losses that fall on the customer because of their own negligence, the directions add a one-time compensation mechanism.

Who can claim: a bona fide individual victim, including a sole proprietor, whose gross loss is up to ₹50,000.
How much: 85% of the net loss or ₹25,000, whichever is less, once in a lifetime. On a joint account, only one holder can claim.
The condition: the fraud must be reported both to the bank and on the National Cyber Crime Reporting Portal (cybercrime.gov.in) or helpline 1930, within five calendar days.
Payment: once the bank finds the claim bona fide it provides the application form, and it pays within five calendar days of receiving the completed application. If money is recovered later, the compensation is recalculated and any additional amount due is paid.
The window: the mechanism covers frauds that occur up to one year from the date the directions take effect.

A worked example: a loss of ₹20,000 with ₹5,000 recovered leaves a net loss of ₹15,000, and 85% of that is ₹12,750. On a net loss of ₹40,000, 85% would be ₹34,000, so the ₹25,000 cap applies.

What the bank must do

Alerts: an instant SMS for every electronic banking transaction above ₹500, and email alerts where an email address is registered, each showing details such as the amount, date, time, channel and beneficiary.
Reporting channels: 24x7 channels, a number in the alert SMS for an immediate objection, a direct fraud-reporting link on the website home page and in the app, and an immediate acknowledgement with a complaint number, date and time.
Resolution: within the bank's own timeline, but no later than 45 calendar days for domestic and 60 calendar days for cross-border fraudulent transactions. Reversals are value-dated to the original transaction date, and credit card frauds get a provisional shadow credit within five calendar days of the customer's report.
Rejections: a bank that rejects a complaint must give its reasons and the supporting details.

What to do the day it happens

Report to your bank first through its 24x7 channel or the fraud-reporting link, and keep the complaint number with its date and time.
Report on 1930 or cybercrime.gov.in the same day. The compensation mechanism needs both reports within five calendar days, and speed is what makes a freeze on the receiving accounts possible.
Keep the trail: the alert SMS, transaction references, and the messages or call details that led to the fraud.
Keep your mobile number and email updated with the bank. Failing to update them after a change is listed as customer negligence.

This article summarises the directions and is not legal advice. The directions themselves, linked below, are the authority.

Questions people ask

What is RBI's five-day rule for online fraud? Under RBI directions effective 1 January 2027, a customer has zero liability for a fraudulent electronic banking transaction caused by a third-party breach if it is reported within five calendar days of the transaction. The one-time compensation for small frauds also requires reporting to the bank and on 1930 or cybercrime.gov.in within five calendar days.

How much compensation can I get if I shared my OTP? If you are a bona fide individual victim and the gross loss is up to ₹50,000, the mechanism pays 85% of the net loss or ₹25,000, whichever is less, once in a lifetime, provided you reported to the bank and on 1930 or cybercrime.gov.in within five calendar days. It covers frauds occurring up to one year from 1 January 2027.

How long does a bank have to resolve a fraud complaint? No more than 45 calendar days for domestic and 60 calendar days for cross-border fraudulent transactions, counted from receipt of the complaint. Reversals are value-dated to the original transaction date.

Sources

Worried a phone was compromised in a fraud? Dunime's Yantrix checks Android and iPhone devices for spyware and remote-access implants.

Published by Dunime Technologies — custom software, automation and cybersecurity, Delhi NCR, India.

PHP2Shell: patch PHP now, then check

Fri, 30 Oct 2026 19:55:54 +0000

Originally published on the Dunime blog.

Two critical PHP flaws let an attacker run code on a web server without logging in. What changed on 21 October, which sites it touches, and what to do today.

If a website runs on PHP, it is in scope. On 21 October 2026 the PHP project shipped fixes for two critical flaws that can let an unauthenticated attacker run code on the web server, and said that updating is the only complete fix.

What changed

On 20 October the PHP security team gave advance notice of a release fixing two critical vulnerabilities, both rated CVSS v4.0 9.2. On 21 October it published PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 with a security advisory headed "update now". The pair is widely reported under the name PHP2Shell.

CVE-2026-109618, code execution via out-of-memory corruption: out-of-memory handling can interrupt PHP while internal request data is only partly set up, and request cleanup may then treat that invalid data as valid.
CVE-2026-109619, code execution via stale global state: internal state belonging to one request can survive after its memory has been freed, and a later request handled by the same worker may use it.

In PHP's words, there are no complete mitigations and updating is the only safe choice. On 23 October PHP added an informational note: keep session.upload_progress.enabled=0 until the next regular bugfix release, to close an unlikely related vector it will document as CVE-2026-115560.

On exploitation: BleepingComputer reported on 21 October that Cloudflare's CTO said the company was already observing early attacks against both flaws before the patches shipped. The UK NCSC alert of the same day asks organisations to update immediately; it does not itself state that the flaws are being exploited.

Who it applies to

PHP's advisory puts every PHP installation that serves web requests at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It rates the risk highest for mod_php, where a demonstrated exploit lets an unauthenticated request trigger the attack before any application code runs.

CMS and web apps: WordPress, Drupal, Joomla, Magento, phpMyAdmin and Nextcloud all run on PHP. Help Net Security, reporting Searchlight Cyber's research, names all six as software on which exploitation has been confirmed. A fully updated plugin or theme does not help if the PHP underneath is unpatched.
Shared hosting and cPanel: on shared hosting the provider usually owns the PHP build. The PHP version picker in the panel shows which branch a site uses, but whether that build carries the 21 October fix is the host's answer to give.
Old PHP: PHP 8.1 and older no longer get updates from the PHP project. Some Linux distributions and long-term-support vendors backport fixes, so ask the vendor. PHP also published minimal source backports for 7.4, 8.0 and 8.1 for people who build from source. PHP 8.2 itself reaches end of life on 31 December 2026.
Agencies and IT teams: anyone who runs sites for others owns an inventory problem today. The NCSC asks for discovery of every PHP installation, internet-facing first, and warns not to limit the search to outdated PHP versions.

Patching the plugin is not patching PHP.

What to do today

1. Find every PHP install. Start with internet-facing sites, then internal tools. Include appliances and products that bundle PHP, and apply their vendors' updates as they arrive.
2. Check the version. On a server, php -v shows the command-line build. The web server can run a different build, so also check the hosting panel or your package manager. Distribution packages may carry the fix under their own version numbering, so confirm with the vendor's security notice rather than the number alone.
3. Update. Move to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or the patched package from your distribution or LTS vendor, internet-facing systems first. Restart PHP-FPM or Apache so every worker runs the new build.
4. If you cannot update yet, reduce exposure. PHP's interim measures narrow specific attack paths but do not make a server safe. They are listed in the next section.
5. If even that is not possible: the NCSC says to consider taking the system offline until it is fully mitigated, and, if it cannot be updated or disabled straight away, to check it for signs of compromise and backdoors first.
6. Check the logs. Look for new or changed PHP files in upload and cache folders, unexpected admin accounts, and bursts of large multipart POST requests, memory-exhaustion errors or crashed PHP-FPM workers. A server that was exposed before patching should be checked, not just patched.
7. Know who to call. Your hosting provider for the PHP build, your application vendor for bundled PHP, and an incident response team if you find signs of compromise. In India, cyber incidents are reported to CERT-In.

Interim mitigations PHP published

Only for systems that cannot be updated immediately. PHP is explicit that these reduce exposure to specific attack paths and do not make an installation safe.

For CVE-2026-109618: set memory_limit=-1 in a way applications cannot override, such as php_admin_value in the FPM pool or Apache configuration, and check nothing sets a finite limit back. Set a low post_max_size: 8M for applications without file uploads, 32M if uploads are needed, with upload_max_filesize below it. Use a container or cgroup limit, ideally one that kills only the affected worker; PHP warns not to substitute RLIMIT_AS or RLIMIT_DATA.
For CVE-2026-109619: set session.upload_progress.enabled=0 in php.ini, the FPM pool or server configuration (not ini_set() or .user.ini) and restart every worker. On PHP 8.5, also set fatal_error_backtraces=0 and restart. Remove invalid or deprecated per-request settings that emit diagnostics, and fix fatal errors and timeouts an attacker can reach.
What does not help: hiding errors with error_reporting, display_errors or the @ operator.

A free scanner, and its catch

On 22 October Searchlight Cyber released php2shell-scanner, a free, open-source command-line tool (github.com/assetnote/php2shell-scanner) that tests whether a host shows the vulnerable behaviour rather than only reading a version number. It first tries to produce a PHP memory-exhaustion error, then looks for a PHP-FPM worker dying mid-request, and only as a last resort reads the advertised PHP version.

The catch: detection deliberately pushes PHP into an out-of-memory condition. The researchers call this "fundamentally risky in nature" and ask for care and caution. Each tested path can receive a small control request and three probes totalling about 29 MiB.
False positives: the README warns that a patched build can return the same empty HTTP 500 when a probe exceeds a low memory_limit, so check any "vulnerable" result against the installed version and vendor backports.
Run it only on systems you own or are authorised in writing to test, and in a maintenance window. It is a check after patching, not a reason to delay the patch.

Questions people ask

What is PHP2Shell? The name widely used for CVE-2026-109618 and CVE-2026-109619, two critical PHP vulnerabilities fixed on 21 October 2026 that can allow unauthenticated remote code execution on web servers running PHP, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed.

Which PHP versions fix PHP2Shell? PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older no longer receive updates from the PHP project; some Linux distributions and LTS vendors provide backported fixes, and PHP published minimal source backports for 7.4, 8.0 and 8.1.

My WordPress site is on shared hosting. What should I do? Check the PHP version in your hosting panel and ask your host whether their PHP build includes the 21 October 2026 fixes. Updating WordPress, plugins and themes does not fix PHP itself. If the host cannot confirm, ask when it will, and follow the NCSC advice for systems that cannot be patched.

Sources

Dunime maps live threats like this one to the specific checks and defences that answer them: dunime.com/now.

Not sure what's exposed? Dunime's VAPT checks whether unpatched services like this are reachable and exploitable across your estate.

Published by Dunime Technologies — custom software, automation and cybersecurity, Delhi NCR, India.

SEO for 2027: A Developer Workflow for AI Search Visibility and Trust

Fri, 30 Oct 2026 19:21:01 +0000

A page can be technically accessible, appear in a search result and still fail to help someone choose a service. An AI answer can mention a business and still describe it incorrectly.

Those are different problems. They need different tests.

I am Jarno Saarimies, founder of AEOvara in Lappeenranta, Finland. I work on SEO and AI search visibility, and I also run a photography business. That combination gives me a useful question to bring to a technical discussion: can a customer actually understand and use what we have built?

For a 2027 planning discussion, I would start with a testable workflow rather than an algorithm prediction. The recommendations below are engineering choices, not promises of higher rankings.

Start with documented requirements

Google's documentation on AI features and websites says that a supporting page in AI Overviews or AI Mode must be indexed and eligible for a search snippet. It does not specify additional technical requirements for those features.

The same guidance recommends accessible textual content, internal links, crawler access and structured data consistent with the visible page. These are eligibility and implementation considerations, not guarantees of selection.

That distinction matters when someone proposes a new AI visibility feature. Ask which documented requirement it satisfies and what observable result would count as success.

Separate discovery from answer quality

I would organise the work around four questions.

Can the page be retrieved? Can its service information be understood? Does an answer represent the business correctly? Can a visitor complete the intended task?

For a service page, my suggested review would cover:

The response status and the canonical URL.
Applicable indexing and snippet directives.
Crawler restrictions at the application, CDN and robots.txt layers.
The important service information in the rendered page.
Internal links that lead to the page.
Agreement between visible content and structured data.
The contact or booking flow on a phone.

Record what was inspected and what was observed. A successful response from one HTTP client does not establish what Google indexed. For Google-specific diagnosis, inspect the page in Search Console as well.

I would avoid collapsing all of this into one pass or fail score. A form validation error and an incorrect service description require different fixes.

Make the service page a useful specification

Consider a hypothetical company booking portraits for ten employees.

The useful questions are specific. Can the photographer work at the office? What is included? How are travel costs handled? When are the files delivered? What information is needed to request a quote?

A developer can turn those questions into acceptance criteria. For example, someone unfamiliar with the business should be able to identify the service area and submit a valid enquiry without asking the owner to explain the page.

This is where I would bring the service provider into the review. Developers can make information accessible, but the owner has to supply accurate scope, prices and limitations.

My proposed content model would include a service name, audience, location, inclusions, exclusions, pricing explanation, process and next action. It is a review template, not a search engine requirement.

Measure four different AI answer outcomes

For AEOvara's visibility work, I use four categories to keep the questions separate: Mention, Recommendation, Citation and Narrative Accuracy.

Here is a proposed operational definition for a test log:

Category	What to record
Mention	Is the target business named?
Recommendation	Does the answer explicitly suggest choosing or considering it?
Citation	Does the answer link to a page on the target domain as supporting evidence?
Narrative Accuracy	Are the factual claims about the business correct?

These are my measurement definitions, not metrics supplied by Google. A different team can choose different definitions, but it should write them down before scoring answers.

Fun fact from that scoring model: an answer can pass the first three categories and fail the fourth. It could name and recommend a company, cite its website, and still invent a service the company does not offer. That is a hypothetical example, but it shows why a citation is not an accuracy check.

For each test, I would retain the exact question, platform, date, language, relevant location and response. Record whether browsing was enabled and any known account or conversation context. Repeat the questions and report the number of observations alongside the results.

Keeping the prompt unchanged improves comparability. It does not control every variable in a changing search or language model system. I would therefore treat a small test as a sample of behaviour, not a market share estimate or evidence that one site change caused the result.

Treat trust as evidence a reader can inspect

Google's people-first content guidance says E-E-A-T is not itself a specific ranking factor. It also encourages accurate authorship information and clarity about how content was produced.

My practical interpretation is to make claims auditable. Name the author, explain the relevant experience, link the primary source and describe the test method. If an example is hypothetical, label it. If a result comes from your own small sample, say so.

A byline cannot substitute for evidence. Neither can a large schema block. For this article, the Google-specific requirements are linked above; the review process and scoring definitions are my recommendations.

Ship one change you can evaluate

For the next iteration, I would choose one important service page, record its current state and fix a concrete problem. That might be missing service information, inaccessible content or a broken enquiry step.

Keep a dated change log. Compare relevant search observations with actual enquiries, and note other changes that could affect the result. A before and after comparison is useful for investigation, but it is not automatically a controlled experiment.

This is how I would approach planning for 2027: documented requirements, explicit definitions and changes small enough to inspect. No forecast about the next algorithm update is needed to start.

About the author

Jarno Saarimies is the founder of AEOvara, based in Lappeenranta, Finland. His work focuses on technical SEO, content clarity and visibility in AI-powered search. He also runs the photography business Kuvaajankulma.

A related article written in Finnish is available at https://aeovara.fi/hakukoneoptimointi-2027/. It covers the broader 2027 planning topic, including predictions. This developer-focused article stands on its own.

What is the hardest part to validate in your projects: crawler access, the accuracy of an AI answer, or whether search visibility leads to a useful enquiry? I would be especially interested in a concrete test that changed your implementation, including one that disproved your original assumption.

Go type yourself!

Fri, 30 Oct 2026 17:47:29 +0000

DHH said that typescript is pure "type masterbation". And though I agree with his premise, It is a fixable problem. And I say we use the type system to do just that.

There is a familiar complaint about TypeScript: too much of the code is types talking to other types. Generic wrappers, schemas restating the same shapes, never tricks to force a switch to be complete. Very little of it does anything at run time.

The complaint is fair, but it usually lands on the wrong target. The TypeScript in a typical full-stack feature is not careless. It is what you have to write to get the guarantees, because TypeScript can't see the parts that matter: what crosses the network, which errors can happen, and whether you handled all of them.

Here is a small, ordinary feature. A page loads a post's title and shows a different message for each way loading can fail.

In TypeScript

// shared/types.ts — the wire contract, stated as types AND as a runtime schema
import { z } from "zod";

export const PostRow = z.object({ title: z.string(), owner: z.string() });
export type PostRow = z.infer<typeof PostRow>;

export type LoadError =
  | { kind: "NotFound"; id: string }
  | { kind: "Forbidden" }
  | { kind: "Unavailable" };

export type Result<T, E> = { ok: true; value: T } | { ok: false; error: E };
export type ApiResponse = Result<string, LoadError>;

// the same contract again, so the client can check at runtime what TS only assumes
export const ApiResponseSchema = z.discriminatedUnion("ok", [
  z.object({ ok: z.literal(true), value: z.string() }),
  z.object({ ok: z.literal(false), error: z.discriminatedUnion("kind", [
    z.object({ kind: z.literal("NotFound"), id: z.string() }),
    z.object({ kind: z.literal("Forbidden") }),
    z.object({ kind: z.literal("Unavailable") }),
  ]) }),
]);

export function assertNever(x: never): never {
  throw new Error(`Unhandled: ${JSON.stringify(x)}`);
}

// app/api/post/route.ts
export async function GET(req: Request): Promise<Response> {
  const id = new URL(req.url).searchParams.get("id") ?? "";
  const viewer = await getViewer(req);
  let row: PostRow | undefined;
  try {
    row = PostRow.optional().parse(
      db.prepare("SELECT title, owner FROM posts WHERE id = ?").get(id));
  } catch {
    return Response.json({ ok: false, error: { kind: "Unavailable" } } satisfies ApiResponse);
  }
  if (!row) return Response.json({ ok: false, error: { kind: "NotFound", id } } satisfies ApiResponse);
  if (row.owner !== viewer) return Response.json({ ok: false, error: { kind: "Forbidden" } } satisfies ApiResponse);
  return Response.json({ ok: true, value: row.title } satisfies ApiResponse);
}

// client
type ClientError = LoadError | { kind: "Transport" };

async function loadTitle(id: string): Promise<Result<string, ClientError>> {
  let res: Response;
  try { res = await fetch(`/api/post?id=${encodeURIComponent(id)}`); }
  catch { return { ok: false, error: { kind: "Transport" } }; }
  const parsed = ApiResponseSchema.safeParse(await res.json());
  return parsed.success ? parsed.data : { ok: false, error: { kind: "Transport" } };
}

function label(r: Awaited<ReturnType<typeof loadTitle>>): string {
  if (r.ok) return r.value;
  switch (r.error.kind) {
    case "NotFound":    return `No post ${r.error.id}`;
    case "Forbidden":   return "Not yours";
    case "Unavailable": return "Try again later";
    case "Transport":   return "Network trouble";
    default:            return assertNever(r.error);
  }
}

In scrml

<program db="./app.db">

type LoadError:enum = { NotFound(id: string), Forbidden, Unavailable }

function loadTitle(id: string, viewer: string) ! LoadError {
    let row = ?{`SELECT title, owner FROM posts WHERE id = ${id}`}.get() !{
        _ :> { fail .Unavailable }
    }
    if (row is not) { fail .NotFound(id) }
    if (row.owner != viewer) { fail .Forbidden }
    return row.title
}

<msg> = ""

function show(id: string) {
    @msg = loadTitle(id, "me") !{
        .NotFound(mid) :> "No post " + mid
        .Forbidden     :> "Not yours"
        .Unavailable   :> "Try again later"
        .Transport(_)  :> "Network trouble"
    }
}

<button onclick=show("1")>Load</>
<p>${@msg}</p>

</program>

Now is'nt that just so much nicer to read?

Where the TypeScript went

TypeScript	scrml
`LoadError` as a union of objects tagged with `kind`	`type LoadError:enum`: variants with payloads are part of the language
`Result<T, E>`, and `ok: true/false` wrapping at every return	`! LoadError` on the signature, `fail .X` in the body. A function that can fail is a language feature, not a library type
A Zod schema restating the wire type so the client can check it at run time	Nothing. `loadTitle` runs on the server because it touches the database, and the compiler writes the encoding for its result and its errors
An API route, a URL, `fetch`, a `try` around `fetch`, and a hand-made `"Transport"` error	`loadTitle(id, "me")` is an ordinary call. A network failure arrives as the built-in `.Transport` variant
`assertNever` and a `default:` branch to make the `switch` complete	The compiler refuses an incomplete handler. Delete the `.Forbidden` line and the build fails: `E-TYPE-080: Non-exhaustive error handler for LoadError. Missing variant(s): Forbidden`
`satisfies ApiResponse` on every `Response.json`	Nothing to satisfy, because no response is written by hand
`Awaited<ReturnType<typeof loadTitle>>`	Nothing to derive, because no type is threaded through generics

The point

None of the TypeScript above is bad. Every line restates something TypeScript cannot see on its own:

the shape of what crosses the wire;
the set of errors a call can produce;
whether every one of them was handled.

You write those types because the compiler is blind to the server, the network and the client as one program.

scrml's compiler is not blind to them. It compiles the server function, the encoding between server and browser, and the client in one pass. So it already knows the error set, already writes the encoding, and can check exhaustiveness itself. You don't need fewer guarantees. You just don't have to restate them by hand.

Random Food Generator

Fri, 30 Oct 2026 17:16:39 +0000

Random Food Generator is a free browser-based tool for anyone who cannot decide what to eat. Choose breakfast, lunch, dinner, a snack, or dessert; narrow the result by cuisine or vegetarian and vegan preferences; or leave every filter open for a surprise. Generate one idea at a time, compare recent picks, and send two or more finalists to the customizable Food Wheel. No account is required, and recent choices stay in the same browser for a quick, low-friction decision.

Hi everyone! I built Random Food Generator because deciding what to eat often takes much longer than it should. It started as a one-click picker, then I added meal, cuisine and diet filters plus a customizable Food Wheel for when you're stuck between two or three options. It's free and needs no sign-up. I'd love to hear which foods or cuisines are missing.

Your App Works Locally. What Changes When It Goes to Production?

Fri, 30 Oct 2026 16:18:42 +0000

Hey, Emmanuel here. While I was pondering what to write about this week, I ran into an old project of mine: Relay (A “real-time” messaging platform). Think Facebook, but without any of the stuff that makes it good, like real people and the ability to actually send friend requests. Truth be told, it’s just a badly designed message board with a fixed amount of people :( that I built to learn about Websockets.

The main thing is that I remembered the absolute nightmare it was to deploy it. It’s not that I haven’t deployed a full-stack application before. No, it’s because the “genius” that made the tutorial decided to build the frontend and backend separately and then eventually move it to the same codebase for a single deployment. He configured a single build command for both ends and a lot of shoddy fixes to get it to work.

Thanks to the experience (PTSD) I got from that project, future deployments became substantially easier. So, that gave me the idea to write about taking your app to production. After building it on your machine, what comes next?

It Works on My Machine. What's the Problem?

Having an app that works on your machine but breaks when it hits production is one of the major rites of passage for developers. When you run your app from your machine, it basically acts as a personal server to handle requests and responses. But that works for just your machine, as someone else making a request to http://localhost:5000 sends it to their own device, not yours.

So, deployment means getting your app out of your device and making it accessible to others. However, a lot, and I mean, a lot of things can easily make things spiral out of control.

While developing locally, you often know exactly where everything is, how it connects, and which configuration values it needs. Deployment forces those assumptions to become explicit. Where does the frontend run? Where does the backend run? How do they communicate? Where is the database hosted? How does the application know which URLs and credentials to use? Those are all questions you need to consider when getting your app out of development and into production.

Your App Needs a Home

Firstly, your app needs a home, which is a server that it runs on. Running it locally doesn’t allow external users on other devices to be able to send requests to your server (I know certain network configurations can let it do that, but by default, it doesn't). Therefore, you need a hosting provider, which is a platform that basically offers you a chunk of their infrastructure to run your application. The exact cloud hosting provider you choose depends on your use case, requirements, and budget. For Relay, however, I used Render (this is my go-to, as their free tier is quite generous).

As you probably know, not every part of your application lives in one place. Usually, you have the frontend of the app, which deals with the client-facing services like the UI, while the backend manages data, logic, and security. Now, the way you deploy your application depends on how you arrange the frontend and backend.

For combined deployment, the frontend is built into static files, and a server serves those files while receiving backend requests. This is actually how I first started web development, using EJS (Embedded JavaScript) alongside Express/Node.js to serve my frontend. With this arrangement, you deploy the whole thing as one, as the backend receives requests directly and serves the appropriate frontend file.

However, I eventually discovered that separate deployment was the popular choice. The frontend and backend are deployed as separate services, usually with different URLs. For Relay, I actually used this arrangement. The React frontend displayed the UI, and the backend provided the core logic, like authentication, messaging, and account creation.

So now, your frontend and backend are now deployed. However, if you used the separate deployment approach, they still need to be able to communicate with one another. So, how do we do that?

The Frontend and Backend Need to Find Each Other

It’s quite obvious that both ends of your application need to communicate to actually work. For that, we use an API (a set of rules and protocols that allows different software applications to communicate and share data with each other). During development, the backend API runs on localhost (something like http://localhost:5000/api/). Hence, the frontend sends requests to that url.

However, when deployed, both ends get live URLs. Back then, I didn’t know most of this, so I wondered why Relay didn’t work when deployed. After a few frustrating minutes, I discovered I was still sending requests to http://localhost:5000/api/ from the deployed frontend. I recommend using environment variables rather than hardcoding these paths, as it’ll be easier to switch between development and production URLs without changing your code.

Of course, there are many other things that can go wrong. In my own case, I also experienced a CORS (Cross-Origin Resource Sharing) error. Keep in mind that this is a security feature designed to stop malicious sites from secretly reading your data on other websites. Notably, tools like Postman or curl don’t enforce CORS, so your API might work during development but fail when it hits production.

Fortunately, CORS errors are straightforward to handle. All you need to do is configure your backend server to include specific HTTP response headers. Setting these headers lets you provide the live frontend URL, list the allowed methods, and even include custom headers. If, like me, you use Express/Node.js for the backend, you can do this by installing the cors package and setting it up.

Where Does Your Data Live?

More often than not, your application might need to access a database for full functionality. However, a database running locally on your development machine isn’t automatically accessible by your deployed application. For this, you use a cloud database service; Supabase, Neon, and AWS RDS can provide PostgreSQL databases, while MongoDB Atlas hosts MongoDB databases.

After setting up a database from any of these cloud providers, you get a connection string. You can then configure your backend to use this connection string for accessing the database. However, DON’T hardcode the connection details in your code; use environment variables to securely pass in the required database access credentials.

I actually used MongoDB Atlas (the tutorial made me do that :( ) while building Relay, so the connection URI was set right from the development stage.

From Localhost to a Live Application

I’ve always heard about deployment issues from other devs, but getting a firsthand experience is something else. Turns out getting an application working locally is a far different game from making it accessible, secure, and reliable once it’s live. However, as I’ve now learned, each frustrating deployment teaches a valuable lesson.

Looking back, Relay wasn't exactly my finest work, but the deployment experience taught me things I wouldn't have learned by simply following a tutorial. Take your time, understand how the different pieces fit together, and don't be afraid to troubleshoot.

🛡️ Mulher Amparada | Personalização, Discrição e Camadas de Autenticação

Fri, 30 Oct 2026 16:01:24 +0000

O Mulher Amparada conta com recursos de personalização visual, discrição e proteção de acesso, integrados para proporcionar uma experiência diferenciada às usuárias.

🎨 Ícone Monocromático e Integração com Material You

O aplicativo oferece suporte aos ícones temáticos do Android (Themed Icons), permitindo que seu ícone acompanhe a identidade visual configurada no dispositivo.

Máscara monocromática: disponibiliza uma versão específica do ícone para utilização pelo sistema Android. Paleta dinâmica: permite que o Android adapte a aparência do ícone às cores escolhidas pela usuária. Integração visual: acompanha a personalização da tela inicial, proporcionando maior consistência com a interface do sistema.

Assim, o ícone não fica limitado às suas cores originais: ele pode assumir a identidade cromática definida pelo próprio Android, sem exigir versões manuais para cada combinação de cores.

🩺 Disfarce do aplicativo: Assistente de Saúde

O Mulher Amparada possui um mecanismo de disfarce visual que apresenta o aplicativo inicialmente como um assistente de saúde genérico.

É apresentada a WelcomeActivity, com uma tela de boas-vindas identificada como Assistente UI 33. O estado da primeira abertura é armazenado por meio da classe Cripto.

⚠️ Importante: os indicadores apresentados na interface de saúde são fictícios e não representam medições, avaliações ou informações médicas reais.

🧮 Segundo disfarce: Calculadora

O aplicativo também disponibiliza uma interface de calculadora, acessível pelo ícone localizado no canto superior direito da tela do assistente de saúde.

Essa interface possui uma funcionalidade adicional de recuperação de acesso, protegida pelo BiometricPrompt.

Caso a usuária esqueça suas credenciais, poderá utilizar a autenticação pelas credenciais do próprio dispositivo para iniciar o procedimento de redefinição.

Após a validação, o sistema solicita as informações de recuperação e a senha, conforme o fluxo implementado.

🔐 Três mecanismos de autenticação e recuperação

O sistema possui três fluxos distintos:

Autenticação pela senha do teclado

A usuária informa sua senha. A interface passa para uma apresentação completamente preta ou branca, conforme o modo de exibição do dispositivo. Cinco toques na tela permitem retornar à interface normal e prosseguir para a HubActivity.

Recuperação pelo toque no visor

A usuária realiza cinco toques na tela em menos de dois segundos para iniciar o procedimento de redefinição. Informa a pergunta de recuperação. Após a validação, a interface passa para a tela preta ou branca. Realiza mais cinco toques. Informa sua nova senha para concluir a redefinição.

Recuperação pelo BiometricPrompt

A usuária acessa a opção de recuperação na interface de calculadora. O sistema solicita a autenticação pelas credenciais do dispositivo (Device Credential). Após a validação, é iniciado o procedimento de redefinição. A usuária confirma as informações solicitadas e passa pela etapa de tela preta ou branca, com cinco toques. Por fim, cadastra uma nova senha e uma nova pergunta de recuperação. 🔒 Cadastro e armazenamento das credenciais

Na configuração inicial, a usuária precisa realizar cinco toques no visor para iniciar o cadastro da senha e da pergunta de recuperação.

As informações são processadas e armazenadas por meio da classe Kotlin Cripto, responsável pelas operações de proteção e gerenciamento dessas credenciais.

O sistema também permite redefinir as informações posteriormente, utilizando os mecanismos de recuperação disponíveis.

💜 Uma experiência construída em camadas

O Mulher Amparada combina:

Personalização visual com Material You. Suporte a ícones temáticos do Android. Interface de assistente de saúde como primeiro disfarce. Interface de calculadora como segundo disfarce. Autenticação biométrica e credenciais do dispositivo. Senha personalizada e pergunta de recuperação. Procedimentos distintos para redefinição de credenciais. Gerenciamento criptográfico das informações de acesso.

Mulher Amparada — tecnologia, discrição e proteção reunidas em uma única experiência. 🛡️

What Access an SEO Audit Actually Needs | FloxoLab

Fri, 30 Oct 2026 15:50:00 +0000

Direct answer: A diagnosis-only SEO audit normally needs the public website URL and Restricted access to Google Search Console. GA4 Viewer access is optional. CMS, hosting, registrar, passwords, billing, and Search Console ownership are implementation or control privileges, not audit requirements.

Access is where trust quietly breaks down between a business and whoever does its SEO. The request usually arrives bundled and casual: send over your website login, your hosting, your Google accounts, and we will take it from here. Most owners hand it over because they do not know which parts are actually needed and which are just convenient for the agency.

What an audit actually needs

An audit is a diagnosis, not surgery. To find the problems holding a site back, the only things genuinely required are your URL and the ability to read your own search data. That is it.

Access or input	Audit need	Safe scope
Public website URL	Required	No login. Include priority pages and any staging boundary.
Search Console	Usually required	Restricted user. This can view most reports but cannot administer the property or submit a sitemap.
GA4	Optional	Viewer. Add No Cost Metrics or No Revenue Metrics restrictions when those values are outside the audit scope.
Business context	Helpful	Priority services, target geography, intended queries, and known competitors.
CMS, hosting, or registrar	Not needed for diagnosis	Grant separately only for an approved implementation task with an owner and end date.

Notice what is not on that list: no website admin login, no hosting panel, no domain registrar, no passwords. A diagnosis is built from reading data, not from holding the keys to the building.

This holds even for the deeper technical part of an audit. Crawling the whole site to surface broken internal links, redirect chains, duplicate or missing titles, and a bloated sitemap is done with a crawler that visits your pages exactly like any other visitor, over the public web. It reads what is already published, so it needs no login at all.

The next step is to combine that public crawl with read-only Google evidence. The Screaming Frog and Search Console audit workflow shows how to reconcile the URL sets without granting implementation access.

How to grant read-only access safely

Both Google tools have a low-privilege viewing role. Add a specific email, choose the lowest role that still exposes the required reports, and remove it when the work is done. These roles do not provide control over your website, domain, or Google account.

Search Console: the Restricted role

In Search Console, open Settings > Users and permissions, click Add user, enter the email you were given, and choose Restricted. Search Console offers Owner, Full, and Restricted. Owner has full control, including adding and removing other users. Restricted has simple view rights on most data, which is all an auditor needs.

Search Console, Settings > Users and permissions. The Restricted role gives read-only view rights, which is all an audit needs. Interface shown as of June 2026.

Restricted users cannot change settings, cannot submit or remove sitemaps, cannot request removals, and cannot touch other users. They can look, and that is the point. When the audit is finished, open the same screen and remove the user.

GA4: the Viewer role

If you want to share Analytics, go to Admin > Property Access Management, add the email, and choose Viewer. GA4 has Administrator, Editor, Marketer, Analyst, and Viewer. Viewer is the read-only floor: it can see report data and settings and build explorations, but it cannot change configuration or manage users.

GA4, Admin > Property Access Management. The Viewer role is read-only: see reports and settings, change nothing. Interface shown as of June 2026.

Prefer not to share access at all? A good audit can still run on exports and screenshots: your Search Console performance, coverage, and a few key reports. It is slightly less thorough than live access, but it keeps you fully in control of what is shared.

What you should never hand over for an audit

If someone needs any of the following just to tell you what is wrong with your site, the request does not match the job. None of these are required to read your data and write a fix list.

Your website admin or CMS password. A login to WordPress, Shopify, or your CMS lets someone change the site, not just read it. An audit changes nothing.
Hosting or cPanel access. Server-level access controls files, databases, and email. There is no audit reason to hold it.
Domain registrar login. Whoever controls the registrar can move or lose the domain itself. Never share it for analysis.
Search Console Owner. Owner can add and remove users and change verification. Restricted is the correct level for an outside reviewer.
Anything financial. Ad accounts with payment methods, billing portals, or card details have nothing to do with an SEO diagnosis.

The pattern is simple. Reading your data needs a read-only role on the data. Anything that can change, move, charge, or delete is not part of finding out what is wrong.

The "no access, no service" red flag

Some providers will not start until they have full back-end access to your site. It is often written into the terms: without admin access, the service cannot be delivered. For an ongoing engagement that implements changes every month, that is at least understandable. For an audit, it is the wrong shape entirely.

Demanding full control before anyone has even told you what is broken inverts the order. You are handing over the keys to buy a diagnosis. A diagnosis comes first, from reading the data, and only then does the question of who changes what, with how much access, even arise. If the only access on offer is all of it, that tells you the product is a retainer, not an audit. (For more on how those retainers are structured, see what a typical SEO retainer actually does.)

Access is also a provider-selection test. The guide to choosing an SEO agency in the Philippines shows how to compare permission requests alongside evidence, deliverables, ownership, reporting, and contract terms.

When backend access is legitimate

There is a real case for deeper access, and it is worth stating clearly so this does not read as if access is always suspect. Once you have the audit and decide to have the fixes implemented, editing the site obviously requires the ability to edit the site.

The difference is that implementation is a separate step, under a separate agreement, with a separate and scoped level of access, granted only for the work being done and removed afterward. That is the opposite of handing over admin up front as a condition of starting. Implementation may require write access; the audit never does. Keeping those two things apart is what keeps you in control.

Access closeout checklist

Use a named individual account instead of sharing a password.
Keep the business-controlled account as the property owner.
Record the role, purpose, approver, and intended removal date.
Grant implementation access under a separate scope, only after the proposed change is approved.
Remove the auditor after delivery and confirm that no temporary verification token or implementation account remains.

The bottom line

An audit reads, it does not write. The honest version needs your URL, a Restricted user in Search Console, and optionally a Viewer in GA4. Everything beyond that is either convenience for the provider or a sign you are being sold something larger than a diagnosis. Grant the viewing roles, keep the keys, and remove access when the work is done.

The fixed-price SEO audit works exactly this way: Restricted Search Console access (or your exports), a technical and on-page review of your site and search data, and a prioritized fix list you own. One report at a flat $150, no retainer, no admin login, no ranking promises. If you choose an ongoing retainer, any access needed to implement an approved fix is scoped separately. Get in touch to start.

Sources checked

Search Console permissions and GA4 roles were rechecked against Google's official documentation on August 2, 2026.

Originally published on FloxoLab.

How to Find Keywords Your Website Is Almost Ranking For

Fri, 30 Oct 2026 15:41:31 +0000

You don't always need to publish new content to improve your website's SEO. Sometimes, your best opportunities are already hiding in Google Search Console.

These are search queries for which your existing pages receive impressions but haven't reached the rankings or traffic you want.

Finding and improving these queries can help you get more value from content you've already published.

Start With Google Search Console****

Open Google Search Console and navigate to Performance → Search results.

Enable all four metrics:

Total clicks
Total impressions
Average CTR
Average position

Choose a date range that provides enough data. If your website receives limited traffic, use a longer period rather than judging performance from a few days.

Find Queries for an Existing Page****

Open the Pages tab and select an article you want to improve.

Next, click the Queries tab.

You'll see the search terms associated with that particular page. Look for relevant queries with impressions but limited clicks.

For example, an article about WordPress speed might appear for searches such as:

How to improve WordPress website speed
Reduce WordPress loading time
Why is my WordPress website slow?

These queries can reveal what Google already considers relevant to your content.

3. Focus on Positions 8–30

As a practical starting point, examine queries with average positions between 8 and 30.

Prioritize queries that have:

Relevant search intent
Meaningful impressions
Room for ranking improvement
A clear connection to your existing article

Don't target every query automatically. An unrelated keyword may indicate a different topic that deserves its own article.

Also remember that average position is an aggregate metric, not your exact live ranking.
**

Improve Content Naturally**

Once you identify a promising query, review your article.

Ask yourself:

Does the content answer the searcher's question?
Is an important explanation missing?
Would a useful example improve the article?
Are the headings clear?
Can relevant internal links help readers explore the topic?

Make focused improvements instead of repeating keywords throughout the content.

If a query represents a completely different search intent, consider creating a separate article.

5. Monitor Your Results

After updating the page, record the changes and date.

Allow Google time to recrawl the content. Then compare clicks, impressions, CTR, and average position using suitable date ranges.

Avoid making additional changes every few days. Give the updated page enough time to collect meaningful performance data.

Final Thoughts

Your existing content may have more ranking potential than you realize.

Use Google Search Console to discover relevant queries, identify content gaps, and improve pages that already receive search visibility.

Instead of publishing more articles just for the sake of publishing, start by improving the opportunities you already have.

Read the complete guide: https://seovixo.com/find-queries-page-almost-ranking-for/

More practical SEO guides and free tools: https://seovixo.com/

Building Knemora: An Open-source, Local-first AI (SI) Second Brain

Fri, 30 Oct 2026 15:23:16 +0000

I’m Federico, a visual designer and full-stack developer.

About six months ago, I had an idea I kept coming back to: could I turn documents and datasets into connected knowledge, explore the relationships visually, and ask questions without sending my material to a cloud inference service?

Why I built Knemora?
After a lot of research, architecture decisions, late nights, and interface iterations, that idea became Knemora.

How it works?
It’s an open-source, local-first AI (SI) Second Brain. You bring your documents and datasets; Knemora compiles knowledge into a portable Markdown wiki, connects pages, and makes that knowledge available through search, a native graph, and chat with source citations.

Architecture:
The diagrams below show the system architecture and the knowledge/inference workflow.

A few choices behind the architecture:

Portable knowledge: Markdown pages with frontmatter and explicit links. The graph is a rebuildable view of those connections.
Local inference: llama.cpp with Qwen3-8B Q3_K_M as the default model.
Retrieval: BM25 search and bounded graph navigation, without a vector database.
Traceability: original documents are preserved, and generated claims carry source references.
Dataset analysis: Polars performs structured calculations, keeping numerical results grounded in computation.

The stack includes Vue 3, FastAPI, Google ADK, SQLite, and Sigma.js/Graphology.

The initial alpha targets macOS Apple Silicon. Node.js 24 with npm is required; the launcher manages the remaining runtimes and model downloads. Initial setup needs internet access, while the core knowledge and inference workflow runs locally afterward. There’s also an isolated demo with interconnected sample knowledge.

As a designer, I care about making the interface clear and the graph useful. As a developer, I care about keeping the underlying knowledge portable and understandable.

Open-source software has helped me throughout my career, and I’m proud to contribute something of my own. This is an early alpha, with plenty left to improve.

Code, documentation, and setup:
github.com/federicolaterra/knemora

Website:
knemora.space

WordPress Crash Recovery & Plugin Conflict Resolution

Fri, 30 Oct 2026 14:36:25 +0000

When a WordPress site crashes immediately after an update, the immediate business impact is lost revenue, disrupted customer workflows, and compromised search standing. In production environments, standard advice like "restore a backup from yesterday" can cause critical data loss: orders placed between the backup and the crash, customer registrations, and recent transactions vanish.

A disciplined engineering approach treats a crashed WordPress site as a contained system failure: isolate the execution failure, restore availability, fix the root cause, and verify data integrity before returning traffic to normal operations.

Common Crash Failure Modes After Updates

WordPress crashes after updates typically stem from four discrete architectural failure modes:

PHP Fatal Errors (Type Errors & Deprecations): A plugin update requires PHP 8.1+ syntax or library extensions that conflict with the server runtime or an older theme calling deprecated functions.
Hook and Filter Signature Conflicts: Two active plugins hook into the same action (e.g., woocommerce_checkout_order_processed or template_redirect) expecting incompatible argument types or returning invalid objects.
Database Schema Migrations & Locked Tables: Complex plugins (WooCommerce, membership tools, custom post-type managers) execute DDL migrations upon activation. If a migration times out or hits MySQL lock contention, queries fail across the application.
Autoloaded Options & Memory Exhaustion: Plugins accumulating transient data in wp_options with autoload = 'yes' spike PHP memory usage beyond memory_limit, triggering fatal out-of-memory crashes on high-concurrency requests.

Systematic Diagnostic Protocol

When diagnosing a crashed WordPress production instance, follow this 5-step engineering triage:

Step 1: Capture Raw Error Logs Without Exposing Stack Traces

Do not enable WP_DEBUG_DISPLAY on a live production URL. Instead, enable debug logging to a private log destination:

// In wp-config.php (before /* That's all, stop editing! */)
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', '/var/log/wordpress/debug.log'); // Secure path outside public web root
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', '0');

Inspect debug.log or the web server error log (NGINX/Apache/FPM error log) to identify the exact file, line number, and exception stack trace.

Step 2: Safe Plugin Isolation via WP-CLI

Avoid renaming the entire wp-content/plugins folder if possible, as this deactivates all plugins and breaks widget and database mappings upon reactivation. Use WP-CLI to isolate the culprit:

# Check status of installed plugins
wp plugin list --status=active

# Deactivate the suspect plugin identified in the error stack trace
wp plugin deactivate offending-plugin-slug --skip-plugins --skip-themes

# Verify frontend HTTP response code
curl -I https://example.com

Step 3: Check MySQL Database Integrity and Migration Locks

If the error indicates missing tables or broken queries, verify table health:

# Check and repair WordPress core and plugin tables
wp db check
wp db repair

# Identify oversized autoloaded options causing memory exhaustion
wp db query "SELECT option_name, LENGTH(option_value) AS size FROM wp_options WHERE autoload='yes' ORDER BY size DESC LIMIT 10;"

Step 4: Patch Compatibility or Pin Version

If the site requires the updated plugin for business operations, evaluate whether a targeted patch (e.g., handling a null object check in a template hook) or a clean version downgrade via WP-CLI is appropriate:

# Safely roll back to previous known-stable version
wp plugin install offending-plugin-slug --version=2.4.1 --force

Step 5: Verification and Regression Testing

Verify that critical customer journeys work end-to-end:

Homepage, archive, and single post rendering
User authentication and session persistence
E-commerce cart, checkout, and webhook callbacks
Scheduled cron tasks (wp cron event list)

When to Seek Engineering Assistance

If a WordPress crash involves corrupted database transactions, custom plugin architecture conflicts, security compromises, or legacy codebase friction, contained engineering intervention restores stability safely.

For rapid assistance with an active failure or production regression, see WordPress & website bug fixing or queue an urgent bug fix. To prevent update regressions entirely with weekly staging tests and daily backups, explore the WordPress Care Plan. If your platform requires broader architecture stabilization, review SazM's Diagnostic Audits or start a direct technical inquiry at the contact page.

Originally published with full diagnostic protocols at SazM: WordPress Crash Recovery & Plugin Conflict Resolution.

Building a static blog with Sitelo, one function per page

Fri, 30 Oct 2026 14:35:56 +0000

In my last post on DEV I explained why I built Sitelo: most websites are documents, and documents shouldn't need a JavaScript application to reach the browser. That post was the argument. This one is the practice.

We'll build a small blog from an empty folder: a home page, post pages generated from JSON files, and a comments section that stays fresh on an otherwise static page. Along the way I'll point out what Sitelo is doing at each step, and what it deliberately doesn't do.

The whole framework fits in one sentence, and it's worth keeping in mind as we go:

Files are routes. Functions return HTML. Browser code is explicit.

Everything below is that sentence, applied.

Step 1: one page is one function

Start with an empty folder and install Sitelo. It needs Node 20.19+ or 22.12+, and Vite is bundled, so there's nothing else to install or configure.

npm init -y
npm pkg set type=module
npm install -D sitelo

Add two scripts to package.json:

"scripts": {
  "dev": "sitelo",
  "build": "sitelo build"
}

Now the first page. Any file in src/ ending in .ht.js is a page, and its default export returns HTML:

// src/index.ht.js
export default () => `
  <html lang="en">
    <head>
      <title>My blog</title>
      <link rel="stylesheet" href="/styles.css">
    </head>
    <body>
      <h1>Hello world</h1>
    </body>
  </html>
`

Create a src/styles.css with a few rules, then run npm run build and you get:

dist/
  index.html   ← your HTML, with <!DOCTYPE html> added
  styles.css   ← bundled and minified, because the page linked it
  404.html     ← a default one, until you write src/404.ht.js

The function ran once, at build time, in Node. The browser gets the string it returned and nothing else: no runtime, no hydration, no bundle of page code. If you want JavaScript in the browser, you add a <script> tag, the same as you would in a hand-written HTML file.

Template literals aren't the only option. A page can also return JSX from a .ht.jsx or .ht.tsx file, which is rendered to a static string with react-dom/server. Or you can use my companion library javascript-to-html, where every element is a function. I'll stick with template literals here because they need no explanation.

Step 2: a layout is just another function

A blog needs the same <head> and header on every page. There's no layout system to learn for this, because a layout is a function that takes some HTML and wraps it:

// src/lib/layout.js
export const layout = ({ title, children }) => `
  <html lang="en">
    <head>
      <meta charset="utf-8">
      <meta name="viewport" content="width=device-width, initial-scale=1">
      <title>${title} · My blog</title>
      <link rel="stylesheet" href="/styles.css">
    </head>
    <body>
      <header><a href="/">My blog</a> · <a href="/blog">Posts</a></header>
      <main>${children}</main>
    </body>
  </html>
`

// src/index.ht.js
import { layout } from './lib/layout.js'

export default () => layout({
  title: 'Home',
  children: '<h1>Hello world</h1><p>Welcome to my blog.</p>',
})

layout.js doesn't end in .ht.js, so it isn't a page. It also never ends up in dist/. Sitelo only emits a JavaScript or TypeScript file when your HTML references it with a <script src>; a module you only import from page code stays on the build side. That rule matters more later, when the helpers you import hold API keys or database code. They can't leak into the browser by accident.

The same rule works in the other direction. Write <script type="module" src="/main.ts"></script> and Sitelo bundles src/main.ts with esbuild, emits main.js, and rewrites the tag to match. Browser code exists only where you asked for it.

Step 3: posts from JSON files

Now for the posts. I'll keep them in the repo as JSON, one file per post, outside src/ because they're content rather than code:

// data/posts/hello-world.json
{
  "title": "Hello, world",
  "date": "2026-10-01",
  "body": "<p>My first post.</p>"
}

The post page lives at src/blog/[slug].ht.js. The square brackets make it a dynamic route, and it exports two more functions next to the page itself:

generateStaticParams() lists the pages to build, one per post.
data() loads what one page needs. Whatever it returns arrives in the page function as data.

// src/blog/[slug].ht.js
import { readJsonCollection } from 'sitelo/data'
import { layout } from '../lib/layout.js'

const posts = () => readJsonCollection('data/posts', { sort: '-date' })

export async function generateStaticParams() {
  return (await posts()).map((post) => ({ slug: post.slug }))
}

export async function data({ params }) {
  return (await posts()).find((post) => post.slug === params.slug)
}

export default ({ data: post }) => layout({
  title: post.title,
  children: `
    <article>
      <h1>${post.title}</h1>
      <time datetime="${post.date}">${post.date}</time>
      ${post.body}
    </article>
  `,
})

readJsonCollection reads every .json file in the folder and takes each slug from its file name. It parses each file once per build, however many pages ask for it, and two posts with the same slug fail the build instead of one silently overwriting the other.

The index page is the same idea without the brackets:

// src/blog/index.ht.js
import { readJsonCollection } from 'sitelo/data'
import { layout } from '../lib/layout.js'

export const data = () => readJsonCollection('data/posts', { sort: '-date' })

export default ({ data: posts }) => layout({
  title: 'Posts',
  children: `
    <h1>Posts</h1>
    <ul>
      ${posts.map((post) => `<li><a href="/blog/${post.slug}">${post.title}</a></li>`).join('')}
    </ul>
  `,
})

A build now writes dist/blog/index.html and one dist/blog/<slug>/index.html per post. In the dev server (npm run dev) pages render on request through Vite, so editing a JSON file reloads the browser, and an error points at the exact line of your page in the terminal.

If your posts live in a CMS instead, data() can fetch them. Sitelo exports fetchWithCache, a drop-in for fetch that caches responses during the build. A 500-page site then doesn't make 500 identical requests to your API.

Step 4: fresh comments on a static page

Comments are the classic reason static blogs reach for a client-side widget or give up and go server-rendered. Sitelo's answer is a server island: the page stays static, and one marked region is rendered on the server when someone views it.

An island is a module in src/islands/ whose default export returns HTML. Islands are fragments rather than pages, so the file is plain .js, not .ht.js:

// src/islands/comments.js
import { getComments } from '../lib/comments.js'

const escape = (s) => String(s).replace(/[&<>"']/g, (c) => `&#${c.charCodeAt(0)};`)

export default async function comments({ props }) {
  const list = await getComments(props.postId)
  if (!list.length) return '<p>No comments yet.</p>'
  return `<ul>${list.map((c) => `<li><b>${escape(c.author)}</b> ${escape(c.text)}</li>`).join('')}</ul>`
}

getComments is whatever your comment store is: a database query, a call to a hosted service. Comments are user input, hence the escape.

Place the island in the post page with island(). The third argument is the fallback HTML that ships in the static build, and when: 'visible' waits until the reader scrolls near the comments before making the request:

// src/blog/[slug].ht.js (the page function)
import { island } from 'sitelo/islands'

export default ({ params, data: post }) => layout({
  title: post.title,
  children: `
    <article>…</article>
    ${island('comments', { postId: params.slug }, '<p>Loading comments…</p>', { when: 'visible' })}
    <script type="module" src="/islands.js"></script>
  `,
})

The script tag loads a two-line client that finds the placeholders and fetches them:

// src/islands.js
import { mountIslands } from 'sitelo/islands/client'

mountIslands()

In npm run dev and sitelo preview this already works: Sitelo serves islands at /_sitelo/islands/<name>. In production your static host serves the pages, and you mount a small handler wherever you can run server code. createIslandsHandler from sitelo/islands/server takes a Web Request and returns a Response, so it fits a serverless or edge function. The repo has Netlify and Vercel versions.

A few details I cared about getting right:

Props are untrusted. They're embedded in the page and sent back on the request, so anyone can edit them. Set SITELO_ISLANDS_SECRET and the build signs every placeholder with HMAC-SHA256, and the handler rejects edited props with a 403.
Islands are server-only. The rule from Step 2 applies: nothing references comments.js from HTML, so it never reaches dist/, and neither does your database code.
Failure is graceful. If the island endpoint is down or slow (10 seconds by default), the fallback HTML stays where it was. The page still works.

Step 5: let the build check your work

The blog works. The last step is a config file, and it's where Sitelo earns its keep on a real site:

// sitelo.config.js
export default {
  site: 'https://myblog.example',
  rss: {
    site: 'https://myblog.example',
    title: 'My blog',
    description: 'Latest posts',
    routePrefix: '/blog',
  },
  images: true,
  linkCheck: 'error',
  lighthouse: {
    thresholds: { accessibility: 100, 'best-practices': 95, seo: 100 },
  },
}

Here's what each line buys you:

site generates dist/sitemap.xml from every route, including the ones generateStaticParams produced.
rss writes dist/rss.xml with an item for every page under /blog.
images turns each <img> into a resized, WebP srcset with width and height set, so a 3000px hero photo no longer ships to phones. It needs sharp installed, and it works in the dev server too, so what you see is what you ship.
linkCheck: 'error' resolves every internal <a href> against the files the build actually wrote, the way a static host would. A typo like /blgo fails the build with the page it's on.
lighthouse gives sitelo lighthouse thresholds to enforce. Any score under its threshold exits non-zero, so it can gate CI. Like sharp, Lighthouse is an optional install.

I left performance out of the thresholds on purpose. It depends on the machine running the audit, and a page that scores 100 on a laptop can score around 60 on a shared CI runner. Accessibility, best practices and SEO are properties of the HTML itself, so they score the same anywhere.

One check needs no config. If a page links a script or stylesheet that doesn't exist in src/ or public/, the build fails and lists the paths it tried. That's why Step 1 asked you to create styles.css first.

Every build ends with a report of what you're shipping: file counts and sizes per type, the largest files, and how long each phase took. On a static site, "how much JavaScript am I sending?" should be a number you see every time, not something you go looking for.

Building it with a coding agent

I designed Sitelo with coding agents in mind, and the small surface area matters even more for them than for people. Ask an agent to add a page to an unfamiliar framework and it reaches for whatever it has seen most: React components, Next.js conventions, Astro frontmatter. With Sitelo there's less to get wrong, because there's less of everything. A page is a function, a route is a file, and browser code is a <script> tag.

To close the remaining gap, Sitelo ships two Agent Skills: one for the framework (pages, routing, data, islands, deployment) and one for its component library. Install them into your project and Claude Code, Cursor, Codex and other agents load them when a task needs them:

npx skills add Paul-Browne/sitelo

The skills also ship inside the npm package, matching the version you installed. Sitelo's test suite checks every API the skills mention against the package's real exports, so a renamed or removed API fails the tests before it reaches a release. For agents that prefer to read a URL, the docs publish sitelo.dev/llms.txt, plus a single-file llms-full.txt with every guide in Markdown.

The build checks from Step 5 help here too. An agent that invents a stylesheet path or links to a page that doesn't exist gets a failed build naming the problem, not a site that quietly ships broken.

What we built, and when not to use it

In five steps we went from an empty folder to a blog with:

a home page, a post index and one page per JSON file
comments rendered on the server at view time, on otherwise static pages
a sitemap, an RSS feed and responsive images
a build that fails on broken links and missing assets, plus a Lighthouse gate for accessibility and SEO

The browser receives HTML, one stylesheet and a 1.7 kB island loader. That's all, because those are the only things we asked for.

Sitelo isn't the right tool for everything. JSX pages render to static HTML only, so onClick handlers and hooks do nothing in the browser. If you're building an application, with client-side state and routing, use an application framework. Astro, Next.js and Eleventy are all excellent at what they do. Sitelo is for docs, blogs, marketing sites and content sites, where "view source" should show what you wrote.

If that sounds like your next project:

Docs: sitelo.dev/docs
Code (MIT licensed): github.com/Paul-Browne/sitelo
Package: npmjs.com/package/sitelo

The repo includes a complete blog example that goes further than this post, with Markdown posts. And if you find something that makes Sitelo more complicated than it needs to be, please open an issue. Keeping it boring is the whole point.

Developer Weekly Briefing — October 30, 2026

Fri, 30 Oct 2026 13:55:46 +0000

Security dominated this week, but not in the usual way. Two active campaigns turned GitHub configuration files into attack surfaces. Researchers demonstrated that the built-in browsers inside AI coding tools can read your SSH keys. And at Oracle AI World in Las Vegas, three separate announcements showed how Oracle is thinking about agent identity, governance, and deployment in enterprise systems. There was a lot to track. Here's what matters.

Two GitHub campaigns, one weak point: your config files

Researchers this week documented two separate attack campaigns targeting GitHub repositories — and both are still active.

Wiz Research named the first one Gheist. It planted more than 13,500 malicious branches across 850-plus accounts. The payloads encode secrets in base32 to slip past GitHub's credential-scanning log masking, and they target private repositories and GitHub Enterprise Server — the approval hold GitHub applies to first-time contributors only covers public repos on github.com, so Enterprise Server customers have no equivalent protection. Gheist isn't looking for source code. It's looking for credentials.

JFrog named the second campaign testmetest. It hijacked 42 real repositories and planted malicious hooks inside AI tool configuration files: .claude/settings.json, .gemini/settings.json, .cursor/mcp.json, and .vscode/tasks.json. Payloads run 12.9–13.7 MB — large enough that GitHub code search won't surface them. The attack runs as soon as someone opens the repo in an affected tool.

Mitch Ashley of The Futurum Group put it plainly: "Agent configuration has become the newest build script in the repository, and review processes have not caught up."

The practical steps are the same for both: audit what's in your AI tool config files, treat them the same as build scripts, and limit the secrets available in any environment where agents run. If you're on GitHub Enterprise Server, check what protection you actually have for first-time contributors on private repositories — it may be less than you think.

AI coding tools can read your SSH keys — two are still unpatched

Researchers at Forever Security documented a vulnerability class they're calling EMBRACE. The attack vector: the built-in browsers inside AI coding tools have access to the host machine's file system. A single click on an assistant-generated HTML link can read your SSH private keys, .env files, and npm tokens from anywhere on disk.

Five tools are affected — Cursor, GitHub Copilot, OpenAI Codex, VS Code, and Claude Desktop. Cursor patched the issue October 1. Copilot fixed it in v1.1.29 on October 13. As of October 29, Codex and VS Code were still unpatched.

The mechanism is simple enough to explain in a sentence: the built-in browser runs with the same permissions as the editor, not as an isolated sandbox. When an agent generates a link and you open it in the built-in browser, that page can reach files the browser has no business touching.

If you use Codex or VS Code with built-in browser features enabled, the current workaround is to open assistant-generated links in an external browser until patches ship. It's also worth auditing what credentials live in places a browser process could reach — SSH keys, .env files, and token files sitting in obvious locations.

Flint runs 40B parameters locally — and keeps your code off someone else's server

Recursive, led by former Salesforce chief scientist Richard Socher, released Flint this week: a 40-billion-parameter mixture-of-experts model designed to run on a developer's machine rather than through a cloud API. With a mixture-of-experts architecture, it activates only about 2.5 billion parameters per token. Recursive reports over 125 tokens per second on an M4 Pro MacBook Pro, with a 512,000-token context window.

Weights are on Hugging Face under Apache 2.0 and the model works with llama.cpp, Ollama, LM Studio, and vLLM. A quantized build needs at least 24GB of RAM; Recursive recommends 48GB for agentic coding workloads. OpenHands is a launch partner, and there's a free hosted version on OpenRouter if you want to try it before committing hardware.

The business case for local models is straightforward: no per-token API fees and source code never leaves your machine. Recursive claims Flint leads mixture-of-experts models under 50B parameters on agentic coding benchmarks — those are the company's own numbers, not independently verified. Mitch Ashley of The Futurum Group flagged the implication for teams: "Evaluation becomes continuous work, tested against each team's own code before a model reaches the pipeline." A benchmark on someone else's code isn't the same as a benchmark on yours.

SAP's CTO says building the agent is now the easy part

At SAP TechEd 2026, SAP CTO Philipp Herzig said something developers probably already sense but rarely hear from a vendor executive: "Building is, quite frankly, the most unimportant part these days."

The harder problems, in his framing, are testing, governance, and token cost. SAP's answer is Joule Studio, its agent-building environment, which now includes a CLI with MCP connections, a built-in sandbox, and auto-generated unit tests. SAP also announced the SAP Enterprise AI Gateway, in preview now and scheduled for Q1 2027, which handles routing, rate limiting, and cost controls across the agents a company runs.

On the data side, SAP Business Data Cloud adds a lakehouse layer built on Dremio and Apache Iceberg.

SAP cited an internal comparison showing 30 hours to build an agent with Claude Code versus 2 hours with Joule Studio. That's SAP's own benchmark, and Joule Studio knows SAP's data models in ways a general-purpose coding tool doesn't. Take it as a claim, not a proof. But the underlying point — that tools with domain knowledge built in will reduce setup time on domain-specific problems — is reasonable.

For developers building on SAP, the Gateway announcement is worth tracking. If it ships on schedule in Q1, it gives teams the enforcement layer Herzig described, with controls that apply before the agent executes, not after.

Oracle gives each agent its own identity

At Oracle AI World, Oracle announced the Oracle AI Security Mesh, a framework designed for enterprises running multiple agents across sensitive data. The core idea: each agent gets its own identity, a defined task scope, and just-in-time permissions rather than standing access.

The architecture has a few pieces worth understanding. OCI Identity Assurance handles authentication, including biometrics. OCI Zero Trust Packet Routing enforces policy at the network layer, below the application — which means an agent can't bypass the controls by manipulating the software above them. Each agent also gets an independent monitor, separate from the agent itself.

Oracle didn't announce a general availability date or pricing.

This lands a week after the Gheist and testmetest campaigns, which both targeted credential theft through misconfigured agents. The timing is coincidental, but the relevance is real. The question Oracle's framework raises — and doesn't fully answer — is how you verify that the identity and permission assignment worked the way you intended. That's what attestation is supposed to solve, and it's still the hardest unsolved problem in agentic AI security right now.

Reddit's r/opensource banned AI tools. It probably won't work. The subreddit's new rules ban AI-assisted contributions, exclude MCP servers, require projects to have multiple contributors and an established community, and will permanently ban users who message moderators seeking exceptions. Linux took the opposite approach — Torvalds said the kernel "is not one of those anti-AI projects" and dropped its AI-disclosure requirement, shifting the burden to accountability: understand your code, regardless of what tools you used. The better model for DevOps teams is probably closer to Linux: hold contributors accountable for what they submit, build CI gates that shift review costs back to submitters, and avoid policies that require judgment calls you can't make consistently. Read more
IBM Z Atlas maps your entire mainframe before you touch anything. IBM's new tool for z/OS builds an AI-searchable map of the entire stack — programs, data sets, JCL, subsystems — so teams can understand what they're changing before they change it. IBM reports 60–80% less time spent gathering context, and analysis that used to take hours running in minutes. On-premises only; public preview October 27, GA in Q1 2027. Requires z/OS 3.1+. The AI reasons and synthesizes, but the underlying data is deterministic — you can trace any answer back to the source. Read more
F5 and NVIDIA draw a hard line between data residency and sovereignty. F5's Ahmed Guetari stated the distinction directly: "Data residency is where data sits. Sovereignty is who controls it." The joint offering layers NVIDIA OpenShell and F5 AI Guardrails on BIG-IP Next for Kubernetes, with enforcement on NVIDIA BlueField DPUs at the hardware layer. Token-aware cost controls and two live deployments — Telenor in Norway and Indosat in Indonesia — are already running. Read more
Oracle's Fusion Setup Registry puts enterprise configuration into a public Git repo. Oracle published the Fusion Setup and Configuration Registry (FSCR) — machine-readable setup skills for Fusion Cloud Applications that AI agents can run. The registry covers dependencies, sequencing, and validation, and an early adopter reported 80% reduction in design and configuration work during implementation. Lexington Health is the only customer data point so far. The repository is public, so you can read the skills before committing to them. Read more
Bito's Governor cut one team's coding agent costs 48% by fixing the search loop. Privado used Bito's Governor to reduce the number of times its coding agent re-searches the codebase for context it already found. The result was a 48% reduction in token costs. Short version: agents that re-retrieve context they've already gathered are expensive, and the fix is stopping the loop rather than switching models. Read more
Oracle plans post-quantum TLS for Java 8 and 11 in late 2027. Hybrid post-quantum key exchange for TLS 1.3 is GA in JDK 27. Java 21 and 17 get it in the first half of 2027; Java 8 and 11 in the second half. There's a condition: the backport date holds only if the team gets enough testing feedback on current builds. If you're on Java 8 or 11, the slow path is waiting. The faster path is pointing a JDK 25 or 27 client at your post-quantum-capable endpoints now and filing what breaks. Read more
Larry Ellison says Oracle Health modules plug into Epic with no data migration. Ellison's pitch at Oracle AI World: turn on the module, it finds the relevant staff, records, and labs through existing SMART on FHIR interfaces, and you're done. The oncology module was the main example. Early adopters should have the full suite by February 1. No demo, no independent validation, and no published technical documentation on which FHIR resources the modules read and write. That's work for the teams who get early access. Read more

Developer Spotlight this week

Yaoshen Luo builds agent evaluation frameworks — and writes about the times they failed him. Based in Shanghai, he built a benchmark from scratch when customer complaints about a voice agent told him the model scores weren't the problem. The test set skewed toward longer sentences than real traffic, and accuracy dropped once he resampled to match production. His earlier lesson: he built an agent that passed every benchmark, shipped it to volunteers for a non-profit project, and they refused to use it again. Not because the model was wrong. Because the workflow didn't fit how they actually worked. His take: the workflow is part of the evaluation, not something you test after.

Watch the conversation

The through-line this week is that agent security is moving from theoretical to active. Gheist and testmetest are already running. EMBRACE vulnerabilities are patched in some tools and open in others. The configuration files developers add to repos for AI tooling are now a real attack surface. Oracle, SAP, and F5 all shipped security and governance frameworks this week — which is a sign that vendors know the problem is real. Whether any of those frameworks hold up in practice is a different question, and the answer won't come from a keynote.

See you next Friday.

Developer Weekly Briefing is published every Friday on Coder Legion. Written by Tom Smith.

php2shell: two ways PHP corrupts its own memory, and why turning that into a shell is still hard

Fri, 30 Oct 2026 13:40:16 +0000

A single unauthenticated request can run code as your web worker on PHP before 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35. The bug is real, the patch is out, and reliable exploitation outside a lab is far harder than the headlines suggest. This is the full analysis, and an honest account of how long it took to prove (and why so long).

Lab-only research on a patched vulnerability. Knowledge sharing, not a how-to.

If you read nothing else, do these five things

Upgrade now to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35. These fix CVE-2026-109618 and CVE-2026-109619. On an end-of-life branch, do not hand-apply an isolated source patch on top of the last EOL release: it closes these two CVEs but leaves you exposed to everything else fixed since the branch went out of support. Get a maintained build from your distro or a package maintainer (Ondřej Surý's deb.sury.org, Remi Collet's repo, Red Hat's module streams), which carry patched builds reaching back through 5.6, or upgrade. Check the package changelog for the CVE IDs before you trust any build. On Windows, take the -1 rebuild (8.5.12-1 and friends): that one bundles a separate Brotli 1.2.1 fix for CVE-2026-111497, an out-of-bounds write reachable through the cURL extension when automatic response decompression is on. Different bug, same download.
Set session.upload_progress.enabled=0, and turn off every extension and feature you don't use. The session flag is PHP's own published mitigation. The general habit, shrinking the attack surface, is the part that pays off on the next bug you haven't heard about yet.
If you run mod_php, move to php-fpm. The FPM process model removes an entire class of these chains and isolates workers from the web server. It raises the bar. It does not close the door: I got a shell on FPM too.
Exploiting this in the wild is hard. Not impossible, hard. Every chain is calibrated to one exact build, the heap grooming is fragile, and even with current LLMs doing the heavy lifting it took days of dead-ends to reach a reliable shell. Sansec and Wiz have both reported public "php2shell" PoCs that do not work against a default install.
This article explains the mechanism and the mitigations. It is not a copy-paste exploit kit, and the working lab harness targets the vulnerable 8.5.11 image only.

Credit where it is due

Discovery and analysis: Calif and Wiz. Their public write-ups, along with the PHP source patch, are what let me understand the issue well enough to reproduce it. If you want the discovery story and the wider impact catalogue, read theirs first.

The fix: the PHP team. "Avoid state corruption via bailout", authored by Arnaud Le Blanc, Ilija Tovilo, Jakub Zelenka, Nora Dossche, and Nicolas Grekas. They turned a messy memory-corruption class into a two-line conceptual fix: stop using zend_bailout on OOM, and reset the globals that startup touches.

Review: special thanks to Arnaud Le Blanc for reviewing an early draft and giving sharp, generous feedback that made this write-up more accurate.

Why this wasn't Log4Shell

The response was loud. NSA, the FBI, and the UK's NCSC all told anyone who could not patch immediately to take the affected system offline until it was mitigated; CISA said the same in its October 24 update, and days earlier had reported active exploitation and added both CVEs to its Known Exploited Vulnerabilities list. I would take the "active exploitation" label with a grain of salt. In waves like this, what gets reported as exploitation is often mass scanning and failed attempts. More than one vendor has quietly walked back a confident "actively exploited" claim once someone checked whether the traffic was a scan or a real shell, and this is not a bug that falls to a generic payload. The PHP team never called for shutting servers down. Their guidance was to patch, then apply the config mitigations.

Everyone reached for the Log4Shell comparison. So why wasn't the whole internet on fire? Why targeted hits instead of a mass, worming wave? The answer is in the offsets, and it is the reason this write-up exists.

The root cause: PHP panics by longjmp, and panic skips cleanup

When a PHP request exhausts memory_limit, the engine historically raised a fatal error and recovered with zend_bailout(), a longjmp back to a safe point. That unwind is the problem. A longjmp does not run the cleanup that a normal return would. If the allocation failed halfway through building a data structure, the half-built structure survives, and a global still points at it.

Both CVEs are that same mistake, caught in two different places.

CVE	What it is
CVE-2026-109618 · Bailout state corruption	An OOM during request startup, request parsing, or session handling leaves engine globals pointing at freed or half-initialized memory. The next request on the same worker inherits the mess.
CVE-2026-109619 · Pre-RINIT decode reuse	The upload-progress feature decodes a session before the request re-initializes its globals. With the unserializer left in a dirty state by a prior OOM, that early decode reuses a dangling structure.

The patch stops the OOM from longjmp-ing mid-operation. It defers the out-of-memory error and raises it at controlled chokepoints, an uncatchable UnwindExit while a userland frame is on the stack, and resets the globals that startup reads. 389 files changed, and a pile of new oom_rfc1867_*.phpt tests pin the exact spots where an allocation could fail mid-structure. On the supported branches an ordinary memory_limit hit is now a graceful fatal that still runs shutdown handlers; only a request that blows past a new hard ceiling, 200% of memory_limit, forces the process out with _exit(137). That rework did not reach the out-of-support branches: the fixes carried by distros and maintainers for 7.4, 8.0, and 8.1 take the blunt route and simply _exit(1) on the offending allocation, tearing the whole process down rather than attempting the unwind that caused the bug. Either way, the corrupting bailout is gone.

The primitive: one signed integer turns a session into an arbitrary write

Everything downstream rests on one function in the unserializer. var_tmp_var() hands out scratch slots from a block of destructor entries. It reads how many slots are used, then returns a pointer past them:

// ext/standard/var_unserializer.re  (simplified)
static zval *var_tmp_var_num(php_unserialize_data_t *var_hashx, zend_long num) {
    var_dtor_entries *var_hash = (*var_hashx)->last_dtor;
    ...
    zend_long used_slots;           // <-- SIGNED
    for (used_slots = var_hash->used_slots; ... )
        ZVAL_UNDEF(&var_hash->data[used_slots]);
    return &var_hash->data[used_slots];   // base + used_slots*16
}

used_slots is a signed zend_long. Make it negative and the returned pointer lands before the block, anywhere the attacker can reach. The session decoder then writes the parsed value through that pointer, one 8-byte value plus its type tag per session variable. Control where the block sits and what used_slots holds, and you have a controlled write with controlled data.

With that write, you build a lie: a chunk of memory that PHP believes is an array. The only field that matters is the array's destructor pointer. Aim it at the internal handler for system(), and the moment PHP tears the "array" down, it runs your command.

PHP's array teardown calls pDestructor(&bucket). Overwrite that one pointer with the address of zif_system, put the command where the bucket points, and freeing the array is a shell.

From one write to a shell: the four-request mod_php chain

A single write primitive is not a shell. You still need to know where to write, which means defeating ASLR, and you need something that turns a write into execution. The mod_php chain does both across four requests on one persistent Apache worker. It is pure HTTP. No files on the target, no debugger, no application code. The chain scripts live in off_chain/.

The payoff in B2 is a classic one: a fake PHP array whose destructor pointer is the internal handler for system(). When PHP tears the array down, it calls that "destructor" with attacker-controlled data, and the command runs as www-data.

$ cat out/proof
uid=33(www-data) gid=33(www-data) groups=33(www-data)

Without the leak, every address is a guess, and a guess on a 64-bit ASLR heap is not an exploit. The forged zend_string read in B1 is what makes the rest deterministic.

The leak needs no local access. It rides out on a header the server sends unprompted: when PHP starts a session it writes the session id verbatim into Set-Cookie: PHPSESSID=.... That id is a zend_string, and B1 controls which one.

A1's bailout freed the session-id buffer but left send_cookie=1 and the dangling PS(id) pointer in place. B1 reclaims that freed chunk with a crafted multipart field and overwrites it with a fake zend_string header: a benign refcount and type word, hash zero, and a len field widened to 2048. The character data is left pointing at the surrounding chunk. When the END cleanup emits the cookie, PHP copies len bytes starting from that pointer, so the PHPSESSID value becomes a 2 KB window of live engine memory rather than a 32-character id.

Everything after that is parsing on the attacker's side. parse_leak.php URL-decodes the cookie, walks it in 8-byte steps, and keeps the qwords that fall in the heap range. The pointer that recurs with its low 12 bits equal to 0x7a0 is zval_ptr_dtor, so libphp base is that value minus 0x7b47a0; bucketing the rest by 2 MB chunk recovers the main heap base. Two reads off one response header, and ASLR is gone from outside the process.

Six paths, two execution models, one scorecard

The same primitive reaches code execution through several routes. They are not equal. Some are pure HTTP, one still needs a debugger, and the FPM and mod_php models behave very differently under the same bug. Every path's exact container setup and commands are in RCE_PATHS.md.

Path	Model	What it is	Result
A	mod_php	Four-request chain, `display_errors=On`	shell
B	mod_php	Same chain, stock `php.ini-production`. Pure HTTP.	shell
B2	mod_php	Path B with a `popen` ROP stack instead of a direct call	shell
C	php-fpm	Session-decode reuse, app-visible leak, ASLR on	shell
C2	php-fpm	Path C fired through a `popen` ROP pivot, no forged `execute_data`	shell
E	mod_php	Multipart partial-bucket teardown (path1)	crash is HTTP-only; no native leak and the groom is blocked, so the write needs an external leak or a debugger

Why FPM is the harder target

mod_php runs PHP inside a long-lived Apache worker that shares the server's address space and survives across requests. That persistence is exactly what the four-request chain feeds on. php-fpm exits the worker the moment php_request_startup() fails, so the whole startup-failure class, including path1, simply cannot carry to a second request there. FPM is the more resilient model, and moving to it is good advice.

It is not a fix. The session-decode reuse (Path C) lives in exactly the pre-RINIT window FPM still has, and I landed a clean uid=33 on a stock FPM container. FPM falls two independent ways, in fact: the forged-frame route above, and a data-only variant (Path C2) that carries no fake execute_data at all. It overwrites the destructor with a jump_fcontext stack pivot into a short popen ROP chain, and fires it through the upload-progress hash update's own old-value destructor rather than the teardown. Same leak, same reuse, no forged frame. "Harder" is the honest word. "Safe" is not.

FPM kills the worker on a failed request startup, which is what blocks the mod_php chains. Path C slips through anyway: the upload-progress decode runs before RINIT resets the worker, so request A's dangling d is still there for request B to reuse and overwrite with the same fake-HashTable frame. That pre-RINIT window is CVE-2026-109619.

One more piece of honesty about the FPM result. The mod_php chains run out of memory at the stock 128 MB limit, driven by the request itself. Nothing on the target has to cooperate. The FPM chains here lean on a lab endpoint that hands back the pointer leak and, for determinism, sets memory_limit to 4 MB with ini_set() so a 1 MB session decode is enough to OOM. The 4 MB is a lab convenience, not a requirement. The arming OOM reaches the real 128 MB limit: a session record that declares a huge array count makes the deserializer pre-allocate the whole bucket table, 128 MB from under 5 MB of input, before it parses one element. The constraint the easy framing misses is where the OOM lands. It has to fire inside the session decode, so php_var_unserialize_destroy() is skipped and the context dangles. An ordinary base64 or image-resize OOM in application code aborts in the wrong place and arms nothing. So the FPM chain needs three things from the target, not one: the pointer leak, an OOM inside session deserialization, and attacker-influenced session content to carry that record. Stock PHP hands over none of them, and the leak is still the hardest.

A reader flagged that my FPM lab spoke FastCGI straight to php-fpm, a shortcut, not a requirement. So I reworked the lab to do it properly; the repo ships that path now: the same leak and write travel the full route over plain HTTP through a stock nginx with php-fpm unreachable from outside, and still land uid=33, roughly 6 fresh workers in 10, every miss a clean retry. The FPM result is remote through a normal reverse proxy, not an artifact of reaching php-fpm directly.

What I did leave on the table, deliberately, were routes that lean on an application weakness. If the target calls unserialize() on attacker input the primitive is one request away, but the PHP manual has warned for years that unserializing untrusted input gets you hacked. That is object injection, the application's bug, not PHP's. I wanted the vulnerability shown in core PHP on a stock install, through mechanisms every install ships, not against someone's vulnerable code.

The barrier the PoCs skip: every stage needs the same worker

The chains above share a requirement the lab quietly satisfies. All four requests have to hit the same PHP worker, because the corrupted state the exploit builds lives in that one worker's memory. With a single worker that is free, and a single worker is where I started. On a production server, with a pool of workers behind a load balancer, landing four requests in a row on one specific worker looks like the hardest part of the attack.

In the lab: one worker (apache2 -X, or a single FPM child). Every request lands on it, so the state carries for free. This is where most public PoCs quietly live, and it is not a real deployment.

In production: many workers, a load balancer in front, other clients in the mix. The four stages scatter across the pool, and the state built on one worker is invisible to the next.

The obvious fix, HTTP keep-alive to pin one connection to one worker, does not work here. The chain OOMs twice on purpose, and PHP closes the connection on a bailout: the response is HTTP/1.0 500 ... Connection: close even when the request asked to keep the socket alive, and the next request on it gets EOF. I confirmed it is the SAPI bailout handling and not an unread body: a plain fatal error and a script-level OOM both close the socket the same way. Keep-alive carries a chain of healthy 200s. It cannot carry a chain whose whole point is to run out of memory.

What does work, in the lab, is process pinning: hold every worker but one busy with slow, half-sent requests, so the single free worker serves all four stages. I got this to a clean shell on mod_php, 9 of 10 prefork children pinned, and on php-fpm, 3 of 4 workers pinned with truncated FastCGI records. Both landed uid=33.

Pinning in a lab is one thing. Against a live server it is the noisy option: other clients hit that free worker too, you rarely know how many workers there are, and a fleet of half-sent connections is the shape a WAF or a bored load balancer drops. But pinning turned out to be unnecessary. Behind a stock-default nginx the php-fpm workers share one listen socket and the kernel hands new connections out in a strict round robin, so on a quiet pool the attacker never lands four stages on one worker: they walk the whole pool. Prime every worker, leak every worker, prime again, fire every worker. That is 2N ordinary complete requests for a pool of N, no slow bodies, nothing held open. I ran this end to end through a stock nginx with php-fpm unreachable from outside, on pools of 2, 4, and 8, and it landed uid=33 on every pool. Live traffic perturbs the round robin and I have not measured the hit rate under load, so this is not a one-shot against a busy server. But it refutes the idea that a worker pool behind default buffering is itself a defense. The barrier that actually holds is the next one.

Every number is build-specific

This is why the public exploits don't work on your server. The chain is a list of offsets, and every one of them is pinned to a single compiled binary. Change the PHP build, the distro, or the CPU architecture, and they all move. A PoC calibrated on the author's machine is a crash on yours.

Offset	x86-64	aarch64 (52-bit VA)
mod_php `zval_ptr_dtor`	`libphp+0x7b47a0`	`libphp+0x761b80`
mod_php `zif_system`	`libphp+0x5996e0`	`libphp+0x5314f0`
user-pointer range	`0x700000000000` to `0x800000000000`	`0xf00000000000` to `0x1000000000000`
`BG(unserialize).data`	`bg+0x368`	`bg+0x348`
fpm leak: `BASE` (from leaked pie_ptr)	`pie_ptr - 0x7c9777`	`pie_ptr - 0x6e7810`

I ported the two leak-based paths from x86-64 to a stock ARM server and both worked: the mod_php chain gave a shell in 4 runs out of 5 across randomized ASLR bases, and the FPM chain in 3 out of 3. That port did not need new exploitation ideas. PHP's internal struct layout and allocator bin sizes are identical on 64-bit ARM, so the small-bin spray and the heap grooming carried over untouched. What changed was a short list of symbol offsets and one pointer-range constant. The leak absorbs the rest, because it reads the current build's addresses at run time instead of hardcoding them. The full re-derivation method is in PORTING.md.

The fixed-address FPM variant, and why I left it out

There is a sixth route I built early and then abandoned: an FPM type-confusion that hardcodes every address instead of leaking one. The worker runs under setarch -R with ASLR off, so the PIE base and the reclaimed unserialize buffer d sit at fixed addresses across runs. Two files carry the whole exploit: a session blob sess_T whose values are d-relative pointers into a fake var_dtor_entries table, and a fill payload fillU.bin that sprays that table into the freed block so the signed-used_slots write lands on a crafted HashTable. No leak, no second request to parse one. On the exact build it was tuned against, it drops a shell on the first try.

It is also the only path I could not reproduce on a clean official image. Nothing about the bug changed; the heap did. On the freshly pulled php:8.5.11-fpm the reclaimed d came back 0x495000 away from the address baked into sess_T, so every d-relative pointer in the payload aimed into unmapped memory. Re-deriving d was not enough. The fill groom itself mis-landed: the spray reclaimed the d allocation as its own zend_string, which put the string's length word (0x1fea, 8170) exactly where last_dtor lives at d+0x10, and var_tmp_var then dereferenced 8170 as an entry count and faulted. The fixed address was not stale, it was occupied by the wrong object.

Fixing that is pure allocator choreography with no new capability at the end of it: re-derive d under the probe, rebase every pointer in sess_T and fillU.bin onto the new base, then re-tune the fill part size and count until the reclaim lands on the freed var_dtor_entries block instead of on d, and repeat for the next image release. Path C reaches the same FPM worker with a live leak that reads the current base at run time, so it absorbs all of this for free and ported to ARM with constant edits only (3 shells in 3 runs). The fixed-address variant demonstrates nothing Path C doesn't and breaks on every rebuild, so I left it out of the paths I stand behind. I am keeping the artifacts only as a worked example of how a build-specific heap groom decays, which is the real lesson: an offset is a fact about one binary, not about the bug.

Mitigations, mapped to what they actually buy you

Action	What it does
Upgrade to 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35	Removes both CVEs at the source: no more bailout corruption, no more dirty-state reuse. This is the fix; everything below is defense in depth.
Windows: the `-1` rebuild	Adds Brotli 1.2.1 for CVE-2026-111497, a separate cURL-reachable OOB write. Same PHP runtime, updated dependency.
`session.upload_progress.enabled=0`	Removes the pre-RINIT session consumer the FPM and mod_php session chains rely on. PHP's own stopgap. Does not touch path1.
mod_php → php-fpm	Removes the startup-failure class and isolates workers. Not a cure.
Disable unused extensions and settings	The habit that pays on the next unknown bug. Every decoder you don't load is a decoder that can't be confused, and the same goes for INI switches you do not need: turn off `cgi.fix_pathinfo`, `expose_php`, and any feature your application never uses.
Confine the worker (AppArmor / SELinux / seccomp)	A profile that stops the PHP worker from spawning a shell blocks the `system()` payload, and it bites where `disable_functions` cannot: this bug calls the internal handler by address, so `disable_functions` is bypassed (I confirmed it fires with `system` disabled). Docker makes a tailored profile cheap to apply, though the default Docker profile still allows shell exec. Defense in depth, not a cure: a worker running attacker code can still `readfile()` your `.env`, keys, and source through PHP and hand them back in the response, no shell needed. Only the upgrade removes the bug.

How this was done, honestly

A closing note on the effort, because the "hard even with LLMs" line up top deserves receipts. This is the story of actually building the thing, dead-ends and all.

I did not find this bug, and my first swing at it missed. The night before the patch I heard about it and spent a few late hours trying to reason it out. I got as far as the two parts that matter, a longjmp on OOM and memory_limit, and then told myself the wrong story. I was certain it had to route through serialization and the internal flags around it, so that is where I dug, and that is where I stayed stuck. Some of the information floating around online pointed the same wrong way, and I took it at face value. I'll blame the late hour rather than look too hard at my own incompetence 😆.

Then the patch landed, the shape of the thing got clearer, and the OCD kicked in. I wanted the full what, why, and how, so I set out to reproduce it end to end. The process was deliberate. I wrote up my own analysis first, a long guide and prompt laying out my theory of where the bug lived, how to reproduce it, and the path from there to a shell, then handed the exploration to DeepSeek V4.1 Flash 1017, under one firm rule: when it got stuck or unsure, it stopped and asked me how to proceed instead of guessing. At the dead-ends I gave direction and, a few times, code. We iterated over several days. Whole approaches looked right and went nowhere. The model was a regular, non-abliterated release. No jailbreak, no uncensored fork. A mainstream aligned model, pointed at a patched vulnerability, with a human in the loop the whole way.

The final validation and this write-up were mine, with Claude Opus. That last mile was the real test of the "hard even with LLMs" claim in the TLDR. Getting a shell on a known-vulnerable container is one thing. Getting the same chain to fire reliably, re-deriving every offset by hand for a new build, porting it from x86-64 to an ARM machine, that is where the days went. The AI accelerated the work. It did not trivialize it.

One more thing on the effort, because it matters. I am a PHP core developer. I have been release manager for over 20 PHP releases, I know my way around the engine internals, and I have spent years on the security side. I am not a neophyte poking at a black box, and it still took days of guided work, wrong turns, and hand re-derivation to reach a reliable shell. So when someone tells you they typed "find me an exploit" into a chatbot and out came a working php2shell chain, they are, quite frankly, full of shit. The prompt is not the hard part. The offsets are.

What this bug is, and what it isn't

php2shell is a genuine unauthenticated RCE, and if you run an unpatched PHP you should treat it as one and upgrade today. It is also a reminder that the distance between "a bug exists" and "a stranger owns your box" is measured in offsets, heap state, and days of patient grooming. The patch deletes the bug the whole path is built on, so there is no path left to walk. That is the only outcome that matters. The researchers who found it did the hard part; the PHP team shipped the fix fast; and the footnote is that even with a capable model doing the grinding, turning this into a reliable shell was work. That gap is not a reason to relax. It is why the upgrade is the whole answer.

Corrections welcome

This gets more accurate when people who know more poke holes in it. If I missed a path, botched an offset, or told the story wrong, tell me: email [*Emails are not allowed*](mailto:Emails are not allowed), DM me on X at @iliaa, or find me in the usual Discords :P.

Reproduction harness, per-path notes, and the full offset tables live in the companion repository, github.com/iliaal/php2shell, which targets the vulnerable 8.5.11 images only. Patched releases are the control in every test.

ERP for Malaysian Finance Teams: Improving Accounts Receivable and Payment Tracking

Fri, 30 Oct 2026 13:29:42 +0000

ERP for Malaysian Finance Teams: Improving Accounts Receivable and Payment Tracking

Introduction

Managing accounts receivable and tracking customer payments are essential responsibilities for every finance department. For businesses in Malaysia, particularly small and medium-sized enterprises (SMEs), distributors, manufacturers, wholesalers, and trading companies, maintaining accurate financial records while ensuring timely payments can become increasingly challenging as operations grow.

Many Malaysian businesses still depend on spreadsheets, manual invoice processing, email communication, and disconnected accounting systems to manage their financial operations. These methods may work for businesses handling a small number of transactions, but they often create problems when invoice volumes increase, customer payment terms become more complicated, and multiple departments need access to financial information.

This is where an ERP system in Malaysia can make a significant difference. Enterprise Resource Planning (ERP) software connects accounts receivable, invoicing, customer records, payment tracking, and financial reporting within a centralized platform. It allows finance teams to monitor outstanding invoices, identify overdue payments, automate routine activities, and maintain better control over cash flow.

With the right ERP solution, Malaysian businesses can move beyond manual financial management and build a more organized, transparent, and efficient accounts receivable process.

Understanding Accounts Receivable Challenges for Malaysian Businesses

Accounts receivable refers to the money customers owe a business for products or services delivered on credit. Managing these outstanding payments is important because delayed collections can affect working capital, operational expenses, supplier payments, and overall business stability.

For Malaysian companies dealing with multiple customers, branches, suppliers, and sales channels, accounts receivable management can become complicated without an integrated financial management system.

Some common challenges faced by finance teams include:

1. Manual Invoice Generation and Processing

Many businesses generate invoices manually using spreadsheets or separate accounting applications. Finance employees must enter customer information, product details, quantities, prices, taxes, and payment terms for individual transactions.

This repetitive process increases the possibility of incorrect invoice details, duplicate entries, and delayed invoice delivery.

2. Difficulty Tracking Outstanding Payments

When customer payment information is maintained across multiple spreadsheets, finance teams may struggle to identify which invoices have been paid, partially paid, or remain outstanding.

Without centralized payment tracking, employees spend additional time checking bank transactions, contacting sales representatives, and updating financial records.

3. Delayed Customer Payments

Late payments can create cash flow challenges, particularly for Malaysian SMEs that depend on regular customer collections to cover operating expenses.

Finance teams need visibility into invoice due dates, customer payment histories, and outstanding balances to prioritize collection activities.

4. Limited Financial Visibility

Disconnected accounting and sales systems make it difficult for management to understand the company's actual financial position.

Without real-time reporting, decision-makers may not have accurate information about overdue receivables, collection performance, and expected cash inflows.

5. Complicated Reconciliation Processes

Matching customer payments with outstanding invoices can become time-consuming when businesses receive multiple payments, partial payments, or transfers without clear invoice references.

An integrated ERP system helps reduce manual reconciliation efforts by connecting payment records with customer invoices and financial transactions.

How ERP Software Improves Accounts Receivable Management in Malaysia

An ERP system brings different financial activities together, allowing finance teams to manage customer invoices, payment records, outstanding balances, and accounting information from one platform.

For Malaysian businesses, ERP software can improve accounts receivable management through several important capabilities.

1. Automated Invoice Generation

ERP software allows finance teams to generate customer invoices directly from confirmed sales orders, delivery records, or completed services.

Instead of entering transaction details manually, the system can retrieve relevant information from existing business records.

This helps businesses:

Generate invoices using standardized templates.
Reduce duplicate data entry.
Maintain accurate customer and transaction details.
Track invoice creation and delivery dates.
Apply predefined payment terms.
Maintain consistent financial records.

For example, a Malaysian wholesale distributor processing hundreds of customer orders can generate invoices from completed sales transactions without manually recreating every order in an accounting application.

Automation reduces administrative workloads and allows finance employees to focus on payment monitoring and financial planning.

2. Real-Time Outstanding Invoice Tracking

One of the most valuable benefits of ERP software is centralized invoice visibility.

Finance teams can access customer accounts and identify outstanding invoices without checking multiple spreadsheets or contacting different departments.

An ERP platform can display:

Total outstanding receivables.
Paid and unpaid invoices.
Partially settled invoices.
Overdue customer balances.
Upcoming invoice due dates.
Customer-wise payment information.

This information helps finance managers understand which customers require immediate follow-up and how much money the business expects to collect.

For companies operating across multiple branches in Malaysia, centralized accounts receivable management also provides better visibility into financial transactions across different locations.

3. Automated Payment Reminders and Follow-Ups

Following up with customers about overdue invoices requires consistent communication between finance teams and customers.

When businesses manage collections manually, employees may forget important follow-up dates or spend excessive time preparing payment reminder messages.

ERP software can support structured collection workflows by helping finance teams identify overdue invoices and schedule reminders based on payment due dates.

For example, a business can establish a collection process that includes:

Sending payment reminders before the invoice due date.
Notifying customers when payments become overdue.
Highlighting long-pending invoices.
Recording customer payment commitments.
Tracking collection follow-up activities.

Automated reminders help businesses maintain consistent communication while reducing the administrative burden on finance employees.

4. Better Customer Payment History Management

Understanding customer payment behavior is important for managing credit risk and making informed business decisions.

An ERP system maintains customer transaction histories, including previous invoices, received payments, outstanding balances, and payment delays.

Finance managers can use this information to identify customers who regularly pay late, customers who maintain consistent payment schedules, and accounts that require additional credit monitoring.

For example, a Malaysian manufacturing company supplying products to multiple distributors can review customer payment histories before approving additional credit sales.

This helps businesses establish more informed credit policies and reduce the risk of accumulating excessive outstanding receivables.

5. Simplified Payment Reconciliation

Payment reconciliation involves matching incoming customer payments with the corresponding invoices and recording the transactions accurately.

For companies receiving payments through bank transfers, online banking, and other payment channels, reconciliation can become complicated when transaction references are incomplete or multiple invoices are settled together.

ERP software helps centralize payment records and connect received amounts with customer accounts and outstanding invoices.

Depending on the available banking integrations and payment features, businesses can reduce manual reconciliation activities and improve the accuracy of their accounting records.

Finance teams can also identify:

Unmatched customer payments.
Partial invoice settlements.
Duplicate payment entries.
Unallocated receipts.
Remaining customer balances.

This improves financial accuracy and makes month-end closing activities more manageable.

Improving Payment Tracking Through ERP Integration

Accounts receivable management does not operate independently. It is closely connected with sales, inventory, purchasing, banking, and accounting activities.

When these departments use disconnected systems, finance employees may need to collect transaction information manually before updating financial records.

An integrated ERP solution connects these business functions and creates a more reliable flow of financial information.

1. Integration Between Sales and Accounting

When a sales order is confirmed, the relevant transaction information can flow into the financial management process.

Once the invoice is generated, finance teams can monitor its payment status without manually transferring information between separate systems.

This reduces communication gaps between sales and finance departments.

2. Integration with Banking and Payment Records

Banking integration can help businesses import or retrieve transaction information, depending on the supported banking services and ERP configuration.

Finance employees can use these records to identify incoming payments and reconcile them against customer invoices.

For Malaysian companies handling a high volume of bank transfers, this can improve payment visibility and reduce repetitive data entry.

3. Integration with Customer Relationship Management

Connecting ERP financial information with customer relationship management (CRM) activities gives sales and finance teams better visibility into customer accounts.

For example, sales representatives can understand whether a customer has outstanding invoices before processing additional orders, subject to the company's credit approval policies.

This improves coordination between departments and helps businesses make better customer-related decisions.

4. Multi-Branch Financial Management

Companies operating across Kuala Lumpur, Selangor, Penang, Johor Bahru, and other Malaysian business locations may need to manage customer payments and financial transactions across multiple branches.

An integrated ERP platform can centralize financial information while maintaining branch-wise transaction records.

Management can review receivables, monitor payment performance, and compare financial results across different business locations.

The Role of ERP in Malaysia's E-Invoicing Environment

Malaysia's e-Invoicing requirements have made digital invoicing an important consideration for businesses of different sizes.

The Inland Revenue Board of Malaysia (LHDN) has introduced an e-Invoicing framework that requires businesses to adapt their invoicing and financial processes according to the applicable implementation requirements.

For finance teams, this means maintaining accurate customer information, transaction records, invoice details, and supporting financial documentation.

An ERP system can help businesses organize these activities by connecting sales transactions, accounting records, and invoice management processes.

With appropriate e-Invoicing integration and configuration, businesses can:

Generate invoices using structured transaction data.
Maintain consistent customer information.
Organize invoice records and supporting documentation.
Reduce repetitive manual data entry.
Track invoice processing status.
Connect invoicing activities with accounting workflows.

However, businesses should ensure that their ERP configuration and e-Invoicing integration meet the applicable LHDN requirements. Not every ERP system automatically provides full regulatory compliance without the necessary setup and integration.

For Malaysian finance teams, selecting an ERP solution that supports evolving invoicing requirements can help create a more organized financial management environment.

Important ERP Features Malaysian Finance Teams Should Consider

Choosing the right ERP software requires more than evaluating its accounting capabilities. Businesses should understand whether the system can support their current financial workflows and future operational requirements.

The following features are particularly important for accounts receivable and payment tracking.

1. Accounts Receivable Dashboard

A centralized dashboard helps finance managers monitor outstanding invoices, overdue balances, customer payments, and collection performance.

2. Customer Credit Management

Credit management features help businesses establish customer credit limits, define payment terms, and monitor outstanding balances before approving additional transactions.

3. Automated Payment Allocation

The system should support efficient payment allocation against customer invoices, including partial payments and outstanding balances.

4. Accounts Receivable Ageing Reports

Ageing reports categorize outstanding invoices according to how long payments have remained unpaid.

These reports help finance teams identify overdue accounts and prioritize collection activities.

5. Financial Reporting and Analytics

ERP reporting capabilities should provide insights into receivables, payment trends, customer balances, and cash flow.

6. Multi-Currency Accounting

For Malaysian businesses dealing with international customers and suppliers, multi-currency accounting can help manage foreign currency transactions and exchange rate differences.

7. Audit Trails and Financial Controls

Maintaining transaction histories and user activity records helps businesses improve financial transparency and accountability.

Why ERPNext Can Be a Practical Choice for Malaysian Finance Teams

ERPNext is an open-source ERP platform that provides integrated accounting and business management capabilities.

For Malaysian SMEs, manufacturers, distributors, and trading companies, ERPNext can help connect financial activities with sales, purchasing, inventory, and other operational processes.

Its accounting capabilities include customer invoicing, accounts receivable management, payment entries, payment reconciliation, receivable ageing, and financial reporting.

Some useful ERPNext capabilities for finance teams include:

Sales Invoice Management: Create and manage customer invoices while maintaining transaction records.
Accounts Receivable Tracking: Monitor outstanding customer balances and unpaid invoices.
Payment Entry Management: Record customer payments and allocate them against outstanding invoices.
Receivable Ageing Reports: Identify overdue payments and understand how long invoices have remained unpaid.
Customer Credit Management: Maintain customer credit information and support better financial controls.
Financial Reports: Access accounting reports to evaluate receivables, income, expenses, and overall business performance.
Multi-Currency Support: Manage financial transactions involving different currencies.
Workflow Customization: Configure business processes according to organizational requirements.

Because ERPNext connects accounting with other business functions, finance teams can work with more consistent information across the organization.

However, successful implementation requires proper configuration, data migration, user training, and integration with the company's existing financial workflows.

Best Practices for Improving Accounts Receivable with ERP

Implementing ERP software is only one part of improving financial management. Businesses must also establish clear processes to ensure that the system delivers meaningful operational improvements.

Malaysian finance teams can follow these practices:

1. Standardize Customer Payment Terms

Define clear payment terms for different customer categories. Ensure that invoice due dates and credit conditions are consistently recorded in the ERP system.

2. Maintain Accurate Customer Records

Keep customer names, billing addresses, tax information, contact details, and payment information updated to minimize invoicing errors.

3. Establish a Regular Collection Process

Create a structured follow-up schedule for upcoming and overdue invoices. Assign responsibility for collection activities to the appropriate finance employees.

4. Review Accounts Receivable Ageing Reports

Review ageing reports regularly to identify overdue payments and customers with increasing outstanding balances.

5. Reconcile Payments Consistently

Record and reconcile incoming customer payments regularly rather than allowing unallocated transactions to accumulate.

6. Monitor Key Financial Performance Indicators

Finance managers should regularly evaluate important metrics such as:

Days Sales Outstanding (DSO).
Total outstanding receivables.
Overdue invoice percentage.
Average customer payment time.
Accounts receivable turnover ratio.
Collection effectiveness.

These indicators help businesses understand collection performance and identify areas that require improvement.

7. Train Employees on ERP Workflows

Ensure that finance employees understand invoice generation, payment allocation, reconciliation, reporting, and collection procedures.

Proper user training helps reduce operational mistakes and improves ERP adoption across the finance department.

How to Choose the Right ERP Company in Malaysia

Selecting an ERP implementation partner is an important decision because the quality of implementation directly affects how effectively the software supports financial operations.

Malaysian businesses should evaluate ERP providers based on their technical capabilities, industry experience, implementation approach, customization services, and long-term support.

Before selecting an ERP company in Malaysia, consider the following factors:

Accounting and Finance Expertise: Evaluate whether the implementation partner understands accounts receivable, accounts payable, payment reconciliation, and financial reporting.
ERP Customization: Check whether the system can accommodate your existing payment terms, approval workflows, and financial processes.
Integration Capabilities: Understand whether the ERP can integrate with banking services, payment platforms, CRM systems, and applicable e-Invoicing solutions.
Data Migration: Confirm how existing customer records, outstanding invoices, and historical financial transactions will be migrated.
Implementation Timeline: Request a realistic implementation plan based on your company's business requirements.
Employee Training: Ensure that the ERP provider offers practical training for finance teams and other system users.
Ongoing Technical Support: Evaluate the availability of assistance for system updates, issue resolution, and future business requirements.

The right ERP implementation partner should understand both the software and the financial workflows of your business.

Conclusion

Effective accounts receivable management is essential for maintaining healthy cash flow and supporting long-term business growth. For Malaysian companies managing increasing invoice volumes, multiple customers, and complex payment processes, relying entirely on spreadsheets and manual accounting activities can create unnecessary operational challenges.

An integrated ERP system helps finance teams automate invoice generation, monitor outstanding payments, manage customer credit, simplify reconciliation, and improve financial reporting.

With ERPNext, businesses can connect accounts receivable with sales, purchasing, inventory, and accounting activities within a centralized business management platform.

For Malaysian SMEs, manufacturers, wholesalers, and distributors, adopting the right ERP solution can improve financial visibility, strengthen payment tracking, and create more structured accounting workflows.

Looking to improve accounts receivable and payment tracking for your Malaysian business?

Matiyas Solutions helps businesses implement and customize ERPNext solutions according to their operational and financial requirements. As a Frappe and ERPNext implementation partner, Matiyas Solutions supports businesses with ERP implementation, accounting workflow configuration, process automation, customization, integration, and user training.

Whether you are managing customer invoices manually, struggling with overdue payments, or looking to centralize your financial operations, Matiyas Solutions can help you build a more efficient ERP-driven finance management system.

Get in touch with Matiyas Solutions to explore how ERPNext can simplify accounts receivable management, improve payment visibility, and support your business growth in Malaysia.

Your Website Looks Amazing, But Why Is Nobody Visiting It?

Fri, 30 Oct 2026 13:07:59 +0000

A beautiful website is a great beginning, but beauty alone cannot make a business successful online. Thousands of websites are published every day, yet many struggle to attract visitors, generate leads, or convert visitors into customers.

Why does this happen?

Because many businesses treat Graphic Design, Web Development, and Search Engine Optimization (SEO) as three separate activities. In reality, they are three essential parts of one successful digital strategy.

A website needs more than an attractive appearance. It needs a strong visual identity, reliable technical performance, and a strategy that helps people discover it through search engines.

Let's explore why these three skills must work together and how they can transform an ordinary website into a powerful digital business asset.

1. Graphic Design: The First Impression That Builds Trust

Imagine visiting two websites.

The first website has outdated colors, confusing layouts, inconsistent fonts, and poor-quality images. The second website has a clean design, balanced colors, professional typography, and an organized layout.

Which one would you trust?

Most visitors will feel more comfortable exploring the second website.

That is the power of Graphic Design.

Graphic design is not simply about making things look beautiful. It is about communicating a message visually, creating a consistent brand identity, and helping people understand a business.

A professional graphic designer considers several important elements:

Brand Identity: Consistent colors, typography, logos, and visual elements help customers recognize a business.
Visual Hierarchy: Important information should receive attention first.
User Experience: Graphics and layouts should make information easier to understand.
Emotional Connection: The right visual style can create confidence and encourage engagement.
Mobile-Friendly Design: Visual elements should remain attractive and readable on smaller screens.

For example, an online clothing store needs more than attractive product photographs. It needs clear product presentations, readable descriptions, consistent branding, and visually organized categories.

Good graphic design makes a website memorable. Great design makes the customer journey easier.

2. Web Development: Turning Creative Ideas into Reality

A beautiful design is only valuable when it works properly.

This is where Web Development becomes important.

Web developers transform design concepts into functional websites using technologies such as HTML, CSS, JavaScript, PHP, Python, and modern content management systems like WordPress.

However, modern web development involves much more than writing code.

A professional website should deliver:

Fast Loading Speed: Visitors should not have to wait unnecessarily for pages to load.
Responsive Design: The website should work smoothly on mobile phones, tablets, and desktops.
Easy Navigation: Visitors should find information without confusion.
Security: Websites should follow appropriate security practices and use reliable updates.
Technical Reliability: Forms, buttons, menus, and other features should work correctly.
Scalability: The website should be capable of supporting future business growth.

Consider an example.

A customer visits an online store because they like a product advertised on Facebook. However, the website takes too long to load, the product images do not display properly, and the checkout process is confusing.

What happens?

The customer may leave without purchasing anything.

This demonstrates why technical performance matters.

A successful developer does not simply build a website that looks good in a browser. They build a website that provides a reliable experience for real users.

3. SEO: Helping the Right People Discover Your Website

You can have the most attractive website and excellent development, but if your target audience cannot find it, your online visibility may remain limited.

This is where Search Engine Optimization (SEO) plays a significant role.

SEO helps search engines understand website content and helps businesses improve their visibility in relevant organic search results.

However, SEO is not about randomly adding keywords to every page.

It requires research, planning, useful content, technical improvements, and continuous optimization.

Important SEO activities include:

Keyword Research

Understanding what potential customers search for is the foundation of an effective SEO strategy.

For example, someone searching for "affordable WordPress website design" may have a different intention from someone searching for "what is WordPress?"

Understanding search intent helps you create content that matches users' needs.

On-Page SEO

Every important page should have a clear title, useful headings, relevant keywords, descriptive URLs, and valuable content.

Image alt text and internal links can also help users and search engines understand your pages.

Technical SEO

Technical SEO focuses on website accessibility, crawlability, indexing, mobile usability, site structure, and performance.

A technically confusing website can make it harder for search engines to discover and understand its content.

Content Marketing

Publishing useful articles, tutorials, guides, and answers to customer questions can help establish credibility and attract relevant audiences.

Performance Monitoring

SEO requires regular analysis. Google Search Console and Google Analytics can help website owners understand search performance and visitor behavior.

Remember: SEO is a long-term process. No ethical SEO professional can guarantee a specific Google ranking.

4. Why Graphic Design, Web Development, and SEO Must Work Together

Here is where the real opportunity begins.

Imagine a business launching a new website.

A graphic designer creates a beautiful interface, but the developer does not optimize its performance.

The developer builds a technically functional website, but the content structure is confusing.

An SEO specialist researches valuable keywords, but those keywords are not reflected naturally in the website's pages.

The result?

The business has three professionals working independently, but the website is not delivering its full potential.

Now imagine a different approach.

The graphic designer creates a user-friendly visual experience.

The developer builds a responsive, accessible, and technically reliable website.

The SEO specialist helps structure pages, improve discoverability, and develop content based on search intent.

All three professionals collaborate from the beginning.

This creates a stronger digital foundation.

Here is how their contributions connect:

Skill	Main Contribution
Graphic Design	Visual identity and user experience
Web Development	Functionality and technical performance
SEO	Search visibility and organic discovery

When these disciplines support each other, businesses have a better opportunity to attract relevant visitors and turn them into customers.

5. Five Common Website Mistakes That Businesses Should Avoid

Even businesses with attractive websites can make mistakes that affect performance.

Mistake 1: Designing Only for Desktop

Many people browse websites using mobile devices. A desktop-only design can create a frustrating experience for mobile visitors.

Solution: Test every important page on different screen sizes.

Mistake 2: Ignoring Website Speed

Large images, unnecessary scripts, and inefficient code can affect loading performance.

Solution: Optimize images, reduce unnecessary resources, and monitor Core Web Vitals.

Mistake 3: Publishing Content Without Keyword Research

Writing articles without understanding the audience's questions and search intent can limit their usefulness.

Solution: Research relevant topics and create content that genuinely answers users' questions.

Mistake 4: Using Poor Navigation

If visitors cannot find services, contact information, or important pages, they may leave.

Solution: Create a simple menu and logical website structure.

Mistake 5: Forgetting Conversion Optimization

A website can attract visitors without generating inquiries or sales.

Solution: Use clear calls to action, accessible contact options, useful service information, and a straightforward conversion process.

6. The Future Belongs to Professionals Who Understand All Three Skills

The digital industry continues to evolve.

Artificial intelligence, automation, modern development frameworks, and changing search experiences are creating new opportunities and challenges.

Businesses increasingly need professionals who understand how different digital disciplines connect.

A graphic designer who understands basic SEO can create more search-friendly visual content.

A web developer who understands user experience can build more effective websites.

An SEO specialist who understands web development can communicate technical recommendations more effectively.

You do not necessarily need to become an expert in all three fields. However, understanding their relationship can make you a more valuable digital professional.

Continuous learning, practical projects, and collaboration are essential for staying relevant.

7. A Practical Checklist for Building a Better Website

Before launching your next website, consider these questions:

Is the design professional and consistent with the brand?
Is the website responsive across different devices?
Are pages easy to navigate?
Does the website load efficiently?
Are the images optimized?
Does every important page have a clear purpose?
Is the content useful and relevant to the target audience?
Have relevant keywords and search intent been considered?
Are titles, headings, and meta descriptions properly structured?
Can visitors easily contact the business or take the next step?

These questions can help identify opportunities for improvement before and after launch.

Final Thoughts: A Website Should Do More Than Look Beautiful

A successful website is not created by design alone, development alone, or SEO alone.

It requires a thoughtful combination of all three.

Graphic Design attracts attention and communicates brand identity. Web Development turns creative ideas into functional experiences. SEO helps the right audience discover valuable information.

When these three disciplines work together, a website becomes more than an online presence. It becomes a platform for communication, customer relationships, brand credibility, and business growth.

Whether you are a graphic designer, web developer, SEO specialist, freelancer, or business owner, remember one important principle:

Don't just build websites that look good. Build websites that work well, provide value, and help people find what they need.

The future of successful digital experiences belongs to those who understand the connection between design, technology, and visibility.

Let's Discuss:

What do you think is the most important factor in a successful website: Graphic Design, Web Development, or SEO?

Or do you believe all three are equally important?

Share your thoughts in the comments. I'd love to hear your perspective.

Should Exact Search Matches Always Come First?

Fri, 30 Oct 2026 13:00:00 +0000

Cover: original AI-generated concept illustration with a fictional interface, not a working product screenshot.

Suppose a workspace has an archived project named Atlas and an active project named Atlas North. Someone types "Atlas" into search. Should the exact title win, or should the project they opened yesterday appear first?

Both orders have a reasonable explanation. The awkward part is making the ranking understandable when the user expected the other one.

A possible compromise is an exact-match section above the broader results, with status and workspace visible on every row. That adds structure, but it also gives an archived item extra prominence. A simple relevance list is quieter, yet can make a precise query feel ignored.

Would you treat a project name differently from an identifier such as TASK-184? And would you expose an "exact matches only" control, or expect people to learn a query syntax?

How would you balance those choices in a search box used by both occasional visitors and people navigating dozens of times a day?

The 3 a.m. call: why every founder needs an Arun

Fri, 30 Oct 2026 12:30:00 +0000

When I'm stuck badly enough, I call Arun.
He's our CTO.
He's the one person I trust to pick up at any hour.

In the night I broke production, he got a short section.
Four lines and a photo.
This is the longer version, because I think the idea deserves more than four lines.

The idea is simple.
Every founder needs one person who picks up.
Not a mentor you email on Mondays.
Not a group chat.
One person, at any hour, who will actually answer.

The one person who picks up

Arun picks up at any hour.
Which, if you think about it, is frankly suspicious.
Does he sleep? Is he three people?
I've decided not to ask, in case the answer ruins it.

If you want to know who he is, his portfolio does a better job than I would.

What I think a person like that gives a founder is a floor.
"Stuck" stops meaning "stuck forever".
The bad nights still happen.
They just have a bottom.

TrackMy Tech is bootstrapped.
There's no board of investors waiting by the phone.
There's Arichandran, our co-founder and director, there's Arun, and there's the rest of us.
When something breaks, the people in the room are the plan.

Why going it alone is harder than it looks

I'm not the first person to notice this.
Paul Graham put "single founder" near the top of his essay The 18 Mistakes That Kill Startups.
His reasoning is blunt.
"Starting a startup is too hard for one person."
Even if you could do all the work yourself, he says, you need colleagues "to brainstorm with, to talk you out of stupid decisions, and to cheer you up when things go wrong."

That last part is the 3 a.m. call in one sentence.

He also writes that "the low points in a startup are so low that few could bear them alone."
I've had a few low points.
I can confirm they are, in fact, low.

The catch: the people can also sink you

Here's the uncomfortable flip side.
The people around you aren't only your safety net.
They can also be the thing that breaks.

Noam Wasserman, who wrote The Founder's Dilemmas, has studied this for years.
The Harvard Crimson reported that his research drew on data from "nearly 10,000 founders of technology and life sciences startups in the U.S."
His main finding, as the Crimson summed it up: "Startup companies are most likely to fail due to personal disagreements within their management teams."

Not the market. Not the tech.
The people.

The same article notes that 73 percent of founders in his survey decided how to split equity in the first month.
An equal split avoids tension early on, but can cause problems if a co-founder backs out later.
In other words: the hard conversations don't go away if you skip them.
They just wait for a worse moment.

So I don't think the lesson is "have a co-founder, done".
I think it's "have someone you trust, and do the work to keep that trust".

Trust is what makes the call possible

There's a reason the 3 a.m. call works with one person and not with others.
You have to be willing to say "I've messed this up and I don't know why" out loud.

Amy Edmondson has a name for the condition that makes that possible.
In her 1999 paper she describes team psychological safety as "a shared belief held by members of a team that the team is safe for interpersonal risk taking."
She studied 51 work teams in a manufacturing company.
Teams with more psychological safety showed more learning behaviour, and that learning behaviour was linked to better team performance.

Her examples of learning behaviour are worth reading slowly: seeking feedback, sharing information, asking for help, talking about errors and experimenting.

"Asking for help" and "talking about errors" are basically the job description of a 3 a.m. call.
If you're scared of looking stupid, you don't call.
You sit there alone for hours, checking the same code again.

Photo: Pathum Danthanarayana on Unsplash

What I'd tell another founder

None of this is a grand theory.
It's my opinion, from someone who makes that call when he's stuck badly enough.

Decide who you'll call before the crisis. Not during it. In the middle of an outage you won't think clearly enough to pick. Know the name now.
Make it mutual. If you only ever call, it's not trust, it's a helpline. Pick up for them too. Be the person who answers.
Say the embarrassing thing early. The call only helps if you're honest about how badly it's gone. Edmondson's research is basically a long argument for this.
Have the awkward talks on a calm day. Equity, roles, who decides what. Wasserman's findings suggest the skipped conversations are the ones that come back.
Write things down so the call is rarer. Passwords in the right place, deployment steps, when certificates expire, how to roll back. If the answer lives in one person's head, that person gets woken up a lot.

That last one matters more than it sounds.
The goal isn't to call Arun more.
The goal is to call him only when it really can't wait.
He picks up at any hour. That doesn't mean he should have to.

One last thing

Find your Arun.
Then try very hard to need him less.

And if you already have one, maybe send them a thank-you message.
During the day, for once.

FAQ

Do you need a co-founder to start a startup?

Not strictly. But Paul Graham lists "single founder" as one of the mistakes that kill startups, mainly because the low points are hard to carry alone. At the very least, have one person you can call.

What is psychological safety in a team?

Amy Edmondson defines it as a shared belief that the team is safe for interpersonal risk taking. In practice: you can admit a mistake or ask for help without being punished for it.

How do you make late-night emergencies rarer?

Write things down. Deployment steps, credentials, renewal dates and rollback commands should live somewhere the whole team can find them, not in one person's head.

Sources

What next

The outage night, in full: we blamed our code, it was SSL.
Another late-night call, from the other side: I said I would help a friend.

Running an academy? Track My Academy handles attendance, fees, player reports and parent messages.
It's built by TrackMy Tech.

10 STO Development Companies for Digital Securities and Asset Tokenization

Fri, 30 Oct 2026 12:16:01 +0000

Security Token Offerings (STOs) allow businesses to issue blockchain-based tokens that represent securities or rights linked to underlying assets. These assets may include real estate, company equity, debt instruments, and investment funds.

Building an STO platform requires more than token creation. Businesses must consider how tokens represent ownership rights, how transfers are restricted, how investors are verified, and how transactions are recorded. Smart contracts, identity verification, investor management, and secondary-market integrations also play important roles.

Choosing an experienced STO development company can help businesses build the technology needed to issue and manage security tokens. However, not every blockchain development provider offers the same capabilities. Some specialize in custom software development, while others provide dedicated tokenization platforms or security token infrastructure.

This article compares 10 companies worth evaluating for STO development in 2027, highlighting their service focus and the types of projects they may suit.

1. Debut Infotech

Debut Infotech provides stablecoin development services, including custom stablecoin creation, smart contract development, blockchain integration, wallet development, and payment solutions. Among stablecoin development companies, it offers businesses technical support for building, deploying, and managing stablecoin projects based on their requirements.

2. Antier Solutions

Antier offers dedicated security token offering development services. Its solutions cover equity tokens, debt tokens, asset-backed tokens, and security token exchange platforms.
The company also describes tokenization use cases involving real estate, art, venture capital funds, and other assets. Its STO services include smart contract development and exchange-related infrastructure.

3. SoluLab

SoluLab is a blockchain development company listed in GoodFirms' STO development category. Its broader blockchain portfolio includes Ethereum tokens, decentralized applications, DeFi platforms, and Web3 products.

For an STO project, businesses should discuss its experience with security token standards, transfer restrictions, investor verification, and regulated token issuance rather than assuming that general token development covers every STO requirement.

4. Nadcab Labs

Nadcab Labs provides blockchain and Web3 development services, including smart contracts, cryptocurrency exchanges, token creation, wallets, and DeFi applications. Its work covers several components that may be required when building a security token platform.
The company is also listed in GoodFirms' STO development category. Businesses should confirm its experience with permissioned security tokens, investor eligibility controls, and compliance-related transfer rules.

5. Crypton Studio

Crypton Studio develops custom blockchain products, smart contracts, tokenization platforms, crypto exchanges, and Web3 applications. Its technical services cover blockchain architecture, tokenomics, development, and security-related work.

Its tokenization and custom blockchain capabilities may be relevant to STO projects that need tailored infrastructure. However, businesses should verify its specific experience with regulated security token issuance.

6. Solicy

Solicy offers blockchain development services covering smart contracts, decentralized applications, wallets, DeFi applications, and Web3 integrations. GoodFirms also lists the company in its STO development category.

For an STO project, its smart contract and blockchain engineering capabilities are worth evaluating. The key question is whether its team can implement security token standards, transfer restrictions, and investor verification requirements.

7. Vegavid Technology

Vegavid Technology provides blockchain and digital product development services. Its broader technology portfolio includes blockchain applications and solutions for businesses across several industries.

The company appears in GoodFirms' STO development category. Businesses considering it should request examples of security token projects and clarify whether the proposed engagement covers token issuance, compliance-related functionality, and investor management.

8. ScalaCode

ScalaCode is a software development company with experience in custom applications and digital platforms. GoodFirms includes it in its STO development category, with its listed blockchain capabilities covering smart contracts, digital asset tokenization, cryptocurrency wallets, and decentralized applications.

Businesses should confirm the availability of a dedicated security token development team and relevant regulated tokenization experience before proceeding.

9. CLARISCO

CLARISCO offers dedicated STO development and security token exchange services. Its published offerings include security token smart contracts, investor dashboards, KYC/AML integrations, token issuance, and secondary-market connectivity.
The company also describes support for token standards such as ERC-3643 and ERC-1400. These are relevant technical considerations for projects that require permissioned token transfers and investor eligibility controls.

10. Blockchain Technologies

Blockchain Technologies is an Australian blockchain development company offering decentralized technology solutions. Its published company profile describes blockchain and Web3 development work, including enterprise-oriented blockchain applications.
GoodFirms lists the company in its STO development category. Businesses should independently verify its current security token services, particularly experience with regulated issuance and asset-backed tokens.

Conclusion

Choosing an STO development partner requires a clear understanding of both blockchain technology and the requirements of digital securities. Businesses should compare providers based on their experience with security token issuance, smart contracts, investor management, asset tokenization, and relevant integrations.

The 10 companies discussed above offer different capabilities. Debut Infotech and Antier have dedicated STO service offerings, while other providers bring broader blockchain development and tokenization experience. CLARISCO also publishes specific STO platform and exchange services.
Before making a final decision, review actual project examples, request technical proposals, and establish which legal, compliance, and development responsibilities each provider will handle.

Segurança em CI/CD: a importância de estudar, auditar e aprender com pipelines de bons projetos

Fri, 30 Oct 2026 12:10:32 +0000

Pipelines de CI/CD são frequentemente tratados como simples mecanismos de automação: executam testes, compilam aplicações, geram artefatos e realizam deploys. Entretanto, eles também representam uma das superfícies de ataque mais importantes de um ambiente de desenvolvimento moderno.

Um pipeline possui acesso a repositórios, tokens, credenciais, registries, ambientes de produção, dependências externas e, em muitos casos, permissões para modificar recursos de infraestrutura. Isso significa que uma falha na configuração de um workflow pode ultrapassar os limites do processo de build e comprometer toda a cadeia de entrega de software.

Por esse motivo, estudar a segurança de pipelines deve fazer parte da rotina de engenharia, assim como revisar código, analisar dependências e avaliar configurações de infraestrutura.

Mais importante do que simplesmente executar ferramentas de análise é compreender por que determinada configuração representa um risco, em quais condições ela pode ser explorada e quais mecanismos realmente mitigam esse risco.

1. Por que estudar pipelines é tão importante?

Um pipeline inseguro pode transformar uma alteração aparentemente simples em um vetor de comprometimento.

Considere alguns exemplos:

Um Pull Request pode introduzir código executado em um runner que possui acesso a credenciais.
Uma interpolação insegura de contextos do GitHub pode permitir injeção de comandos no shell.
Uma dependência comprometida pode executar código durante a instalação.
Um token com permissões excessivas pode permitir alterações não autorizadas no repositório.
Uma publicação sem mecanismos adequados de autorização pode disponibilizar uma versão não aprovada de um pacote.
Um workflow mal configurado pode executar código de terceiros com privilégios superiores aos necessários.

Esses cenários demonstram que o pipeline não é apenas uma ferramenta operacional. Ele faz parte da infraestrutura de segurança da organização.

A segurança precisa considerar todo o ciclo de execução: desde o evento que dispara o workflow até as permissões disponíveis, dependências instaladas, artefatos produzidos e operações realizadas.

2. Utilize scanners, mas não terceirize o julgamento técnico

Existem ferramentas especializadas em identificar configurações inseguras em workflows.

Algumas opções relevantes que eu utilizo no dia a dia para scans do pipeline:

zizmor: analisa workflows do GitHub Actions e identifica problemas como template injection, permissões inadequadas, uso inseguro de eventos e instalações de dependências fora de manifests.
Checkov: realiza análise estática de configurações de infraestrutura como código e também identifica problemas em configurações de CI/CD.
actionlint: valida a sintaxe, expressões, referências e possíveis problemas estruturais em workflows do GitHub Actions.
OpenSSF Scorecard: avalia práticas de segurança de projetos e repositórios, incluindo dependências, permissões, manutenção e configuração de workflows.
Trivy: além de analisar imagens e dependências, consegue avaliar configurações e arquivos de infraestrutura.

Essas ferramentas são importantes porque automatizam a identificação de padrões conhecidos de risco.

Entretanto, existe uma diferença fundamental entre encontrar uma configuração potencialmente insegura e demonstrar que ela é explorável.

Um scanner identifica padrões. O engenheiro precisa compreender o contexto.

Exemplo: template injection

Considere:

- name: Check changelog
  run: scripts/check-changelog-frozen.sh "origin/${{ github.base_ref }}"

O scanner pode identificar uma possível injeção de comandos porque o contexto é interpolado diretamente no código executado pelo shell.

O risco existe porque o GitHub Actions realiza a expansão da expressão antes de executar o script.

Entretanto, é necessário entender a origem do dado.

github.base_ref representa a branch de destino do Pull Request, enquanto github.head_ref representa a branch de origem.

Um colaborador externo normalmente controla o nome da própria branch, mas não controla livremente a branch de destino.

Portanto, embora exista um padrão vulnerável, a explorabilidade depende das permissões e das condições do workflow.

A correção recomendada é transportar o valor por uma variável de ambiente:

- name: Check changelog
  env:
    BASE_REF: ${{ github.base_ref }}
  run: scripts/check-changelog-frozen.sh "origin/$BASE_REF"

O valor passa a ser tratado como dado, em vez de ser inserido diretamente no código interpretado pelo shell.

Esse exemplo demonstra por que é necessário estudar os findings: o scanner identifica corretamente o padrão, mas a análise de impacto exige conhecimento sobre os contextos do GitHub Actions.

3. Aprenda a diferenciar vulnerabilidades reais de findings parcialmente mitigados

Nem todo alerta representa uma vulnerabilidade diretamente explorável.

Um exemplo interessante é a instalação de dependências durante o pipeline.

Considere:

env:
  CLAUDE_CODE_VERSION: "2.1.296"
  CODEX_VERSION: "0.162.1"

E posteriormente:

- name: Install CLIs
  run: |
    npm install --global \
      "@anthropic-ai/claude-code@${CLAUDE_CODE_VERSION}" \
      "@openai/codex@${CODEX_VERSION}"

Um scanner como o zizmor pode identificar o padrão adhoc-packages, pois os pacotes são instalados globalmente sem um manifesto e lockfile controlando a instalação.

Entretanto, existe uma particularidade: as versões principais já estão explicitamente fixadas.

Isso significa que o workflow não está simplesmente instalando a última versão disponível a cada execução.

Ainda existe uma fragilidade: a árvore completa de dependências não está necessariamente reproduzível, pois as dependências transitivas não são controladas por um lockfile versionado.

É importante distinguir:

Versão principal fixada: controla qual versão direta será solicitada.
Manifesto: declara as dependências do projeto.
Lockfile: registra a resolução das dependências e suas integridades.
Instalação reproduzível: utiliza a resolução registrada para reconstruir o ambiente.

A ausência de lockfile continua sendo um finding válido, mas não significa automaticamente que existe uma instalação de versão flutuante ou que um pacote esteja comprometido.

O objetivo da análise não é eliminar alertas indiscriminadamente, mas determinar quais riscos permanecem e quais controles já existem.

4. Estude como projetos maduros resolvem problemas de segurança

Uma das formas mais eficientes de evoluir na segurança de pipelines é estudar workflows de projetos open source bem mantidos.

Em vez de começar sempre do zero, investigue como projetos com grande exposição pública estruturam seus processos de CI/CD.

Alguns exemplos interessantes para estudo:

Kubernetes: organização de workflows, testes, automação e governança de contribuições.
Terraform: validação, testes, releases e publicação de artefatos.
Trivy: análise de segurança, integração de scanners e automação de releases.
OpenTelemetry: testes distribuídos, validação de componentes e publicação de versões.
actions/checkout: implementação e manutenção de GitHub Actions.
Sigstore: assinatura, verificação e estabelecimento de confiança em artefatos.

Ao estudar esses projetos, não observe apenas quais actions são utilizadas. Investigue as decisões arquiteturais.

Pergunte:

Como o workflow é disparado?
Ele aceita Pull Requests de forks?
Quais permissões são concedidas ao GITHUB_TOKEN?
Existem secrets disponíveis durante a execução?
Como as dependências são instaladas?
As GitHub Actions são referenciadas por tags ou hashes SHA completos?
Como os artefatos são assinados e verificados?
Como as publicações são autorizadas?
Existem ambientes protegidos e aprovações humanas?
Como o projeto separa testes, validação e publicação?

O objetivo é compreender o motivo de cada decisão, e não simplesmente copiar configurações.

Uma configuração segura em determinado contexto pode ser inadequada em outro.

5. Construa uma rotina de auditoria de pipelines

A análise não deve acontecer somente quando um scanner encontra um problema.

Uma rotina de auditoria pode ser incorporada ao próprio processo de engenharia.

Uma abordagem prática:

Etapa 1 — Inventário

Mapear todos os workflows existentes:

CI.
CD.
Release.
Publicação de pacotes.
Provisionamento de infraestrutura.
Automação de dependências.
Segurança e compliance.

Etapa 2 — Análise automatizada

Executar ferramentas como:

zizmor .github/workflows

actionlint

checkov -d .github/workflows

scorecard --repo=github.com/ORG/REPOSITORY

Os comandos devem ser ajustados à versão e à forma de instalação de cada ferramenta.

Etapa 3 — Investigação dos findings

Para cada alerta:

Identificar o trecho responsável.
Entender a regra acionada.
Identificar a origem dos dados.
Verificar se existe controle compensatório.
Avaliar a possibilidade de exploração.
Determinar o impacto potencial.
Definir a correção ou justificar uma exceção.

Etapa 4 — Correção

Priorizar problemas que permitam execução de código não confiável, exposição de credenciais, elevação de privilégios e comprometimento de releases.

Etapa 5 — Prevenção

Incorporar os scanners ao próprio CI para impedir que configurações inseguras sejam introduzidas novamente.

6. Crie um laboratório utilizando projetos reais

Uma estratégia especialmente interessante é escolher projetos open source e realizar auditorias independentes em seus workflows.

Não é necessário encontrar uma vulnerabilidade para que o estudo seja útil.

O exercício consiste em:

Selecionar um repositório ativo e bem mantido.
Baixar ou clonar seus workflows.
Executar os scanners.
Investigar os findings.
Consultar a documentação das regras acionadas.
Comparar a implementação com as recomendações oficiais.
Identificar controles compensatórios.
Propor correções.
Registrar os resultados em um pequeno relatório técnico.

É possível inclusive comparar diferentes projetos para entender como cada equipe resolve o mesmo problema.

Por exemplo: como diferentes projetos implementam Trusted Publishing, como controlam dependências de terceiros ou como protegem workflows executados por Pull Requests externos.

Esse exercício desenvolve uma habilidade importante: sair da posição de alguém que apenas corrige alertas e passar a compreender a arquitetura de segurança do processo de entrega.

Segurança de CI/CD exige conhecimento sobre GitHub Actions, shell, permissões, autenticação, dependências, infraestrutura e supply chain security.

É justamente por isso que estudar workflows de projetos maduros é tão valioso: eles oferecem exemplos concretos de decisões de engenharia, problemas reais e estratégias de mitigação que podem ser adaptadas a outros ambientes.

Conclusão

Scanners são instrumentos de diagnóstico, não substitutos do conhecimento técnico.

Executar um scanner e aplicar todas as correções sugeridas sem entender os findings pode gerar configurações desnecessárias, exceções mal justificadas e até novos problemas.

O caminho mais consistente é combinar análise automatizada, estudo da documentação, investigação técnica e comparação com implementações de projetos reconhecidos.

Estudar pipelines de bons projetos é uma forma de aprender com decisões de engenharia que já foram colocadas à prova.

Afinal, um pipeline seguro não é aquele que simplesmente passa em todas as verificações. É aquele cuja arquitetura foi compreendida, cujos riscos são conhecidos e cujos mecanismos de proteção foram implementados de maneira consciente.

One Notebook That Says Four Words

Fri, 30 Oct 2026 11:45:05 +0000

The housing lease regulation states that housing rental enterprises shall establish housing rental files and truthfully record the relevant information.

The same phrase "record truthfully," applied to an apartment vacant for six months, becomes who went in to look, and what they saw.

A caretaker holds dozens of properties. The notebook says "checked." Who pressed it, and when — all from memory.

And another sector is blunter still: the complaints book at one gym says "service attitude." At one driving school, the complaints register often says "service attitude" as well.

Put this week's five items side by side and they aren't five sectors' problems. They're one recording habit appearing in five places.

The outside already requires either "record truthfully" or "put it in the contract." The inside writes "checked" or "service attitude."

Five Sectors, One Notebook That Says Four Words

Sector	What the outside requires	What the inside actually writes
Property management	Enterprises shall establish rental files andtruthfully record relevant information	One photocopied inspection sheet for everything; notebook says "checked," and who pressed it is memory
Yoga & fitness studios	Prepayment requires a written contract specifying how the prepayment is refunded and what counts as breach	Sessions remaining, validity period, and booking records sit in three places— front desk, instructor, finance
Travel agencies	Itinerary, vehicle, meals, meeting times must be typed into a sheet the customer can read	Passport expiry is checked by eye; missing one is often found on departure day
Flower & plant retail	Public survey: loss rates in the flower distribution chain run 10% to 15%	Arrival date, how many days it can still hold, whether it went into the fridge — nobody writes it down
Long-term rentals	Rental files record truthfully; roughly 80% of tenants accept five years or more	The property sheet has two columns, layout and rent. Vacant or occupied — unmarked

The gap looks the same in all five: nobody is missing a sheet. The columns that already have a rule behind them got written as a few words.

And the external requirements in these five sectors get more specific all the time:

Housing lease regulation: enterprises shall establish housing rental files and truthfully record relevant information
The Consumer Association's report notes that prepaid consumption problems concentrate in education and training, entertainment and fitness, and beauty and hairdressing; the regulations require a written contract when prepayment is taken, specifying how it is refunded and what counts as breach
The Ministry of Culture and Tourism's statistical bulletin: over 64,000 travel agencies nationwide, with more than 560 billion in annual revenue; in the same year those 64,000-plus firms together earned only 3.78 billion in operating profit
A public survey puts flower loss rates in the chain from origin to store at 10% to 15%
A public industry survey finds roughly 80% of tenants accept terms of five years or more, and the longer the term the harder it is to settle in one go; the same survey names the top three things that drive renewal: repair response speed, property quality, and cleaning frequency

And the work all five sectors need to do is actually the same thing: sorting.

Which units to inspect first ──→ Which classes first ──→ Whose documents first ──→ Which area first ──→ Which listings to show
   ↓                              ↓                            ↓                       ↓                  ↓
 machines produce inspection   machines produce a timetable  machines produce the     machines produce a      machines produce a
 sheets by unit state, lease    by instructor slots, class    itinerary draft and a     delivery sheet by       matching list by layout,
 milestone, inspection record   capacity, card balance       checklist from itinerary  order time, stem       rent range, move-in date
 humans decide when to knock    humans decide whether to      elements, document        life, route order       humans decide which to show
 whether to warn the tenant      swap shifts, cross-store     expiry, meeting times     humans decide substitute first, price

One: Property management — "record truthfully," applied to a flat vacant six months

The housing lease regulation states that housing rental enterprises shall establish rental files and truthfully record relevant information.

The same phrase "record truthfully," applied to an apartment vacant for six months, becomes who went in to look, and what they saw.

A caretaker holds dozens of properties. The notebook says "checked." Who pressed it, and when — all from memory.

The inspection sheet is one photocopied page used for everything. It doesn't distinguish whether anyone lives there or how many months are left on the lease.

A tenant reports a leak. Who goes first, whether to bring materials, whether the landlord has to approve — the caretaker asks around in a group chat.

How long one inspection takes, how many days a repair takes to close — not on the public page.

Scheduling inspections and prioritising them was always computation. Machines produce inspection sheets by unit state, lease milestone, and inspection record — occupied, nearing expiry, and vacant go on three different sheets.

Repairs are prioritised by impact, with leaks and tripped breakers pushed to the top, and whoever attended and whether it's finished stay on the same ticket.

When to go over, whether to warn the tenant first, whether the landlord pays — the caretaker decides.

Two: Yoga & fitness — sessions remaining, validity, and bookings in three places

The Consumer Association's report notes that prepaid consumption problems concentrate in education and training, entertainment and fitness, and beauty and hairdressing.

The regulations also require a written contract when prepayment is taken, specifying how the prepayment is refunded and what counts as breach.

How many sessions are left on this card, which month it runs to, whether it works at another store — the member asks once, and the front desk searches once.

Instructors' slots are on a whiteboard: who's full, who swapped shifts, which room is free — all maintained by erasing and rewriting.

Sessions remaining, validity period, and booking records sit in three different places — one with the front desk, one with the instructor, one with finance. When they disagree, someone reconciles it by hand.

How many classes a studio books a day, how many card refunds — not on the public page.

Scheduling classes was always computation. Machines produce a timetable from instructor slots, class capacity, and card balances — who's full and which session still has room, flagged directly.

A reminder the night before and again on the day, with sessions remaining and the expiry date landing on one ledger.

Whether to swap shifts, whether a package works across stores, what conditions trigger a refund — the manager decides. The machine doesn't rule.

Three: Travel agencies — passport expiry checked by eye, missing one found on departure day

The Ministry of Culture and Tourism's statistical bulletin: over 64,000 travel agencies nationwide, with more than 560 billion in annual revenue.

In the same year, those 64,000-plus firms together earned only 3.78 billion in operating profit.

One store takes one group. Itinerary, vehicle, meals, meeting times — the coordinator types them into a sheet the customer can read.

Customers send photos of their documents. How long the expiry has to run is scanned by eye, and missing one is often only found on departure day.

When the coach departs, who hasn't arrived, how the luggage gets loaded — the night before, it all runs on roll call in a group chat.

How many items an itinerary sheet covers, how long one last-minute change takes — not on the public page.

Producing the draft was always copying plus checking. Machines generate the itinerary draft and a checklist from itinerary elements, document expiry, and meeting times, item by item, down to the person.

Whose document is about to expire, which section nobody has checked, which day the meeting times don't line up — flagged and pushed to the top.

How the final itinerary is arranged, whether the group runs at all, whether it goes out under minimum numbers — the coordinator decides. The machine doesn't chase.

Four: Flowers and plants — 10% to 15% loss, and nobody writes the arrival date

A public survey puts flower loss rates in the chain from origin to store at 10% to 15%.

At the shop end, what time a bouquet reaches the customer and how long it sat in between — nobody records.

The order book is sorted by time. Orders from the same district and from two streets away are mixed together, and who does what first comes down to whoever is free.

Which day this bouquet arrived, how many more days it can hold, whether it went into the fridge — nobody at the counter writes it down, it depends on whoever handled the delivery.

At midday the orders bunch up. The cold-chain van can make one run, so flowers in another district sit in the shop and wait.

How many write-offs a store reports a day, which column compensation lands in — not on the public page.

Delivery order was always a scheduling problem. Machines produce a delivery sheet by order time, stem life, and route order — which district first, and what time it must leave.

Which day a bouquet is on, which order must beat a certain time — line by line on the sheet, with progress recorded at every stop.

What to substitute when one stem is missing, how much to compensate, whether to switch to a different flower — the store decides. The machine doesn't make promises on the customer's behalf.

Five: Long-term rentals — 80% will take five years or more, and the sheet has two columns

A public industry survey finds roughly 80% of tenants accept terms of five years or more, and the longer the term the harder it is to settle in one go.

The same survey names the top three things that drive renewal: repair response speed, property quality, and cleaning frequency.

All three of those live in the caretaker's mouth. The property sheet has two columns, layout and rent. Vacant or occupied — unmarked.

Which month a customer's contract expires, whether they'll renew — the caretaker flips through a paper ledger, and after finding it still has to phone to confirm.

Someone asks whether there's anything cheaper to see. Whether the caretaker shows first or asks about price first depends on the day's mood and who's on shift.

What share of stock is vacant, how many tenants renew on expiry — not on the public page.

Matching is comparison plus sorting. Machines produce a matching list by layout, rent range, and move-in timing — which listings to push first comes out of the sheet.

Contract expiry months get a separate sheet, with the ones approaching listed month by month, and the things to settle before renewal pulled out in advance.

Which unit to show first, on what terms, and how far the price can move — the caretaker decides. The machine doesn't quote.

Five Gaps, One Sentence

Laid out together, the five share a shape:

Sector	What already exists	The missing column
Property management	Units, leases, inspection sheets	The sheet doesn't separate occupied / expiring / vacant; who checked is memory
Fitness studios	Instructor slots, class capacity, member cards	Sessions remaining, validity, bookings — three copies in three places
Travel agencies	Itinerary elements, meeting times	Document expiry scanned by eye
Flower retail	Order times, route order	Arrival date, stem life, fridge status — unwritten
Long-term rentals	Layout, rent	Vacant or occupied unmarked; contract expiry in a paper ledger

And each of these five gaps has its external clock already written down:

Housing lease regulation: truthfully record relevant information
Prepaid consumption: a written contract is required when prepayment is taken, specifying how it is refunded and what counts as breach
Travel agencies: 64,000-plus firms, 3.78 billion in operating profit for the year — and a missed document is found on departure day
Flowers: 10% to 15% loss in the distribution chain
Long-term rentals: roughly 80% accept five years or more, and longer terms are harder to settle at once

What this round is really about: the work all five sectors need is the same thing — sorting. And sorting needs one precondition: knowing what the current state of each item actually is.

Property management: whether anyone lives there, and how many months are left on the lease
Fitness studios: how many sessions are left, and which month it runs to
Travel agencies: when this person's document expires, which section nobody checked
Flower retail: which day this arrived, how long it can hold, whether it's been chilled
Long-term rentals: vacant or occupied, and which month the contract expires

All five of those numbers exist in their own notebooks. None of them are on the sheet that gets sorted.

This Round's Judgement

Walking all five, this round's conclusion differs again:

Earlier rounds were about "the information is between two sections." This round is about "the record stops at four words."

W41's pet services: six checkpoints between a dog walking in and walking back
W43's cross-industry: property, government, eyewear, baby retail, parcel returns — one thing done wrong
W44's cross-industry: five sectors, one sentence — "I'll decide"
This round: five sectors, one notebook that says four words

And the problem with writing "checked" or "service attitude" isn't carelessness. Once those four words are written, nothing downstream can be sorted.

What machines take on here is one class of work: wire the columns that already exist into the sheet that actually gets sorted.

Sector	The sheet machines produce	The sentence that stays human
Property management	Inspection sheets by unit state, lease milestone, inspection record	When to knock, whether to warn the tenant, whether the landlord pays
Fitness studios	Timetable by instructor slots, class capacity, card balances	Swap shifts, cross-store packages, refund conditions
Travel agencies	Itinerary draft and checklist by elements, expiry, meeting times	Whether the group runs, whether it goes out under minimum
Flower retail	Delivery sheet by order time, stem life, route order	Substitution, compensation, switching flower types
Long-term rentals	Matching list by layout, rent range, move-in date; expiry sheet	Which unit first, on what terms, how far price can move

In all five the boundary looks nearly identical: machines sort order, people decide exceptions.

What We Can't See

These can only be answered inside each business:

How long one inspection takes, how many days a repair closes, what share of units get missed
Classes booked per day, and how often balance and validity disagree
How many items an itinerary covers, and how long fixing a missed document takes
Write-offs per store per day, and which column compensation lands in
What share of stock is vacant, and how many tenants renew on expiry

These aren't shortcomings — they are part of the deliverable. The unknowns are themselves part of the deliverable.

The Takeaway

These five sectors are a long way apart, but the most expensive habit they share is the same: the housing lease regulation demands "truthful record," which on a flat vacant for six months becomes the word "checked" in a notebook; prepaid consumption demands a contract specifying how refunds work, while sessions remaining and validity sit with the front desk, the instructor, and finance; 64,000 travel agencies earning 3.78 billion in operating profit still check passport expiry by eye, and a missed one surfaces on departure day; flower loss runs 10% to 15% and nobody writes the arrival date; 80% of tenants will take five years or more, and the property sheet has two columns. Machines aren't taking anyone's job; they're wiring the columns that already exist into the sheet that actually gets sorted. What stays is when to knock and whether to warn the tenant, whether to swap shifts and whether packages cross stores, whether the group runs and whether it goes out under minimum, what to substitute and how much to compensate, which unit to show first and how far price can move. Shops still open, coaches still leave. But when the notebook says four words, everything downstream has to be asked one person at a time.

This assessment is based on publicly available information, is exploratory in nature, is not an internal audit, and does not represent the official position of the company in question.

Which industry should we break down next? Drop it in the comments — property services, homestays, pet funeral services, or whichever one finds "checked" hardest to trace afterwards.

Build a bird-feeder camera that sends photos to your phone (ESP32-CAM, one weekend)

Fri, 30 Oct 2026 11:14:48 +0000

"I want photos of birds at my feeder sent to my phone."

A tiny camera board next to the feeder takes a photo when something moves and sends it to your phone. It's cheap and fun; the photos are decent, not wildlife-magazine sharp.

Cost $15–30 · Time one weekend · Level some experience helps · Power USB (solar is harder)

What to buy

Part	Why this one	Rough cost
ESP32-CAM with its USB programming board (ESP32-CAM-MB)	Camera and WiFi on one small board. The add-on board makes uploading code easy.	$8–15
PIR motion sensor (e.g. AM312)	Detects warm, moving bodies. Small and low-power.	$1–3
5V USB power supply, 2 A	The camera and WiFi together draw a lot; weak supplies cause random resets.	$5
Weatherproof box with a clear window	Keeps rain and condensation off the lens.	$5–10

Prices are rough ranges, not quotes. Check the current price and stock before you order.

What to install

An Arduino sketch that wakes on motion, takes a photo and sends it through a Telegram bot (the UniversalTelegramBot library has ESP32-CAM examples). ntfy can take photo attachments too.

Runner-up: a Raspberry Pi with its camera module. It costs more and uses more power, but takes much better photos and can spot motion in the image itself.

Build it in three steps

Take a photo on your desk. Flash the camera web-server example that comes with the ESP32 Arduino package, and view the picture in a browser.
Send one to your phone. Set up the bot, and send a photo when you wave at the motion sensor.
Move it outside. Mount it 30–60 cm from the perch, facing away from the sun, and adjust from there.

What catches people out

Motion sensors miss small birds. PIR sensors are made to spot people; a small bird a metre away may not trigger one. Mount the sensor close to the perch, or take a photo every few seconds and keep only the ones that changed.
Focus. The stock lens is usually focused further away. For close-ups it can be turned carefully to refocus (it's often held by a dab of glue), or move the camera back.
Random resets. "Brownout detector was triggered" in the log means the power sagged. Use a good 5V supply and a short, thick cable.
Solar is a step up. The camera draws a lot while it's awake. Get it working on USB before you try solar.

This guide first appeared on IotMentor, a free chat mentor for small electronics builds (I make it). If your setup is different (distance, power, budget, experience), you can ask it there and it will plan your version.

Build a water-leak alarm for under the sink (ESP32, one evening)

Fri, 30 Oct 2026 11:14:12 +0000

"How do I get warned before a leak under the sink floods the kitchen?"

Water conducts a little electricity. Two metal contacts a few millimetres apart on the cupboard floor, a small board that checks them, a loud buzzer and a phone alert. The test is dramatic: pour a glass of water and it screams.

Cost $6–12 · Time one evening · Level first build · Power USB or battery

What to buy

Part	Why this one	Rough cost
ESP32-C3 board	Small, cheap, WiFi built in.	$4–7
Leak probe: two wires or two screws, a few mm apart	Or a cheap "rain sensor" board with a comparator, which gives a simple wet/dry signal.	$0–2
Active buzzer	Beeps by itself when powered, so no tone code is needed. It still warns you when your phone is off.	$1
A 100 kΩ resistor	For reading the probe (see step 1).	$0.10
USB power (there's often a socket under the sink) or batteries		—

Prices are rough ranges, not quotes. Check the current price and stock before you order.

What to install

ESPHome or a short Arduino sketch: check the probe, sound the buzzer when it's wet, and send a phone alert through ntfy or Home Assistant. Repeat the alert every few minutes until it's dry; a leak is urgent.

Ready-made option: leak sensors for Zigbee or WiFi cost about $10–20. Build your own to learn, or to get a loud buzzer right at the sink.

Build it in three steps

Test with a glass of water. Connect one probe to ground. Connect the other to an analog pin, and through the 100 kΩ resistor to a second pin that you switch on only while measuring. Print the reading dry, and with the probe in water: wet should read clearly lower.
Add the buzzer and the alert. Drive the buzzer from a pin (through a small transistor if it needs more current than a pin can give). Alert once when it turns wet, then every few minutes.
Place it. Probes flat on the lowest point of the cupboard floor; board and buzzer higher up, where they stay dry.

What catches people out

Probes corrode if they're powered all the time. Constant current through wet metal eats it away. Power the probe only for the moment you measure, which is why the resistor goes to a pin, not straight to 3.3V.
Damp isn't a leak. Set the alert point from your own test, well away from the dry reading.
Battery version: wake every 30–60 seconds, check, sleep. A leak takes minutes to do damage, so that's fast enough.
Low voltage only. USB or batteries; never run mains wiring near the water.

AI Privacy: How Much Should AI Know About You?

Fri, 30 Oct 2026 11:13:06 +0000

Your AI Knows What You Want. But Should It Know Everything About You?

Imagine opening a streaming app and finding a film that matches your mood perfectly. You did not search for it, and you did not tell the app what you wanted to watch. It simply appeared in your recommendations.

Now imagine an AI assistant remembering how you work, the products you prefer, the questions you frequently ask, and the way you communicate. It can save time because you no longer need to explain everything from the beginning.

That sounds useful. And often, it is.

But it also raises an important question: how much information should an AI system collect before personalization starts feeling uncomfortable?

This is where AI privacy becomes important. As AI systems become better at understanding individual preferences, the amount of personal information involved in creating those experiences deserves closer attention.

The goal should not be to prevent AI from understanding people. It should be to make sure that convenience does not become an excuse for collecting information without clear limits.

How AI Personalization Actually Works

AI personalization is the process of adapting recommendations, responses, and services to an individual using information about their preferences, behavior, and interactions.

It does not always require a detailed personal profile. Sometimes, a system needs only a few recent interactions to make a useful recommendation.

For example, a shopping platform might notice that someone frequently searches for running shoes. A recommendation system can use that pattern to display related products rather than showing completely unrelated items.

Other systems may use several types of information:

Search and browsing behavior: Pages visited, searches performed, and topics explored.
User preferences and interactions: Content liked, products saved, or responses selected.
Purchase and viewing history: Previous orders, watched videos, or frequently used services.
Location and context: Approximate location, language, time, or device information, depending on permissions.
Conversations and user-provided details: Information shared directly with an AI assistant, such as preferred writing styles or recurring tasks.

Machine learning systems identify patterns in this information. Recommendation algorithms, for instance, can estimate which items a person may find useful based on previous interactions and similarities with other users.

Generative AI can also use conversation context to produce more relevant answers.

However, personalization and permanent memory are not the same thing. A system may use information temporarily during one interaction, store preferences for future sessions, or combine activity across different services. These approaches have different privacy implications.

Understanding that distinction is important when considering how AI uses personal data.

Why AI Needs Personal Data to Be Useful

Personal information can make AI systems more relevant. Without any knowledge of the user's preferences or situation, an AI system often has to provide general answers that may not match the actual request.

Consider an AI writing assistant.

If it knows that a user prefers concise explanations and a conversational tone, it can produce more suitable drafts. The user spends less time correcting the same preferences repeatedly.

The benefits become clearer in everyday applications.

More Relevant Recommendations

Streaming services, shopping platforms, and news applications use interaction patterns to recommend content.

Instead of displaying the same results to everyone, they can prioritize material that appears more relevant to an individual's interests.

This can make large content libraries easier to navigate.

Smarter AI Assistants

An assistant that understands a user's preferred language, formatting style, or recurring workflow can provide more consistent support.

For example, someone who regularly asks for programming explanations may benefit from examples written in their preferred programming language.

The important distinction is that the assistant may need to remember a technical preference, not an unrelated collection of personal details.

Better Accessibility

Personalization can also improve accessibility.

AI systems may adapt text size, simplify complex explanations, generate captions, or support different communication styles.

For someone who regularly uses assistive technology, remembering accessibility preferences can make digital services easier to use.

More Efficient Customer Support

Businesses can use relevant account information and previous support interactions to reduce repetitive questions.

A customer contacting a service about an existing order may not need to explain the entire situation again.

When handled responsibly, this creates a smoother experience.

The benefits are real, but they do not mean every useful feature requires unlimited access to personal information

When Personalization Starts Becoming a Privacy Problem

Personalization becomes uncomfortable when users lose control over what information is collected, how it is used, or how long it remains available.

Imagine asking an AI assistant for help planning a holiday. You provide your travel dates and budget.

Those details may be relevant to the request.

But would you expect the same information to be used later for unrelated advertising, shared with another service, or combined with additional activity to create a detailed profile?

Probably not.

This is where data privacy in AI becomes more than a technical issue. It becomes a question of reasonable expectations.

Collecting More Information Than Necessary

A service may request access to contacts, location, browsing activity, or other information even when its main feature does not require all of it.

Collecting extra data can create additional security and privacy responsibilities without providing meaningful benefits.

A simple principle applies: if a feature works without a particular piece of information, there should be a clear reason before collecting it.

Consent That Users Do Not Fully Understand

Privacy notices can be long and difficult to interpret.

A user might accept permissions to access a feature without understanding whether their information will be stored, analyzed, shared, or used for additional purposes.

Meaningful consent requires more than displaying a long policy and asking someone to click an acceptance button.

People should be able to understand the important consequences of their choices.

Sensitive Information Can Be Inferred

Sometimes, ordinary activity reveals more than users expect.

A pattern of searches, purchases, or content interactions may reveal interests or circumstances that someone never directly shared.

This is particularly important because AI systems can combine different pieces of information and identify patterns that are not obvious when each data point is considered separately.

The privacy concern is not limited to information people intentionally provide. It also includes what systems may infer from their behavior.

Personal Information Used for Unexpected Purposes

Information collected to improve one feature may later be considered useful for another.

For example, a company might collect customer interaction data to improve support recommendations. Using the same information for unrelated profiling introduces a different purpose that users may not expect.

The original reason for collecting data should not become an unlimited permission to use it elsewhere.

The OECD's work on AI, data governance and privacy discusses how AI development creates overlapping questions around privacy, data governance, and responsible data use

The Hidden Risks of Giving AI Too Much Information

The privacy risks of AI personalization are not limited to uncomfortable recommendations. They can affect security, individual choices, and the way organizations make decisions.

Understanding these risks helps explain why AI security and privacy need to be considered together.

Data Breaches and Unauthorized Access

Personal information stored by a service can become a target for attackers.

If a system retains sensitive conversations, account details, or uploaded documents, unauthorized access could expose information users never intended to make public.

The risk depends on the information stored, the security measures protecting it, and how many people or systems can access it.

Collecting less information can reduce the amount of sensitive data exposed in a potential incident.

Exposure of Sensitive Conversations

People may share personal details with AI assistants because the interaction feels private and conversational.

They might discuss workplace problems, financial planning, family matters, or confidential business information.

If a service handles conversation history carelessly, or if account access is compromised, those conversations may become accessible to unauthorized parties.

Users should not assume that every AI conversation has the same privacy protections as a private discussion with a trusted professional.

Behavioral Profiling and Manipulation

Detailed behavioral profiles can help services predict what people are likely to click, purchase, or engage with.

That information can improve recommendations, but it can also create opportunities for manipulative design.

For example, a platform might use a user's behavior to repeatedly promote products or content that encourage impulsive decisions.

The concern is not personalization itself. It is the possibility that personalization may be used to influence people in ways they do not understand or control.

Biased Decisions Based on Personal Data

AI systems may use personal or behavioral information when ranking candidates, evaluating customers, or recommending services.

If the underlying data contains historical bias or reflects unequal patterns, automated decisions may reproduce or amplify those problems.

Even information that appears neutral can act as a proxy for sensitive characteristics.

This makes fairness, explainability, and opportunities to challenge important decisions essential parts of responsible AI development.

Data Retention and Third-Party Sharing

Information may pass through several systems before a personalized service produces its result.

A business could use an AI provider, analytics platform, cloud storage service, or external integration.

Each additional relationship raises questions about access, storage, retention, and responsibility.

Users should be able to understand which organizations process their information and whether the information is retained beyond the original interaction.

Privacy is not only about what an AI model knows. It is also about the wider system handling the data.

Can AI Be Personalized Without Knowing Everything About You?

Yes. Personalization does not require collecting every available detail about a person.

The better approach is to identify which information is genuinely necessary for a feature and design the system around that limited requirement.

Several privacy-focused techniques can help.

1. Data Minimization

Data minimization means collecting only the information needed for a specific purpose.

For example, a language-learning application may need to remember a user's language level and learning progress. It probably does not need access to their entire contact list or unrelated browsing history.

This approach reduces unnecessary collection and limits the information that could be exposed if something goes wrong.

2. Privacy by Design

Privacy by design means considering privacy when a product is being planned and developed, rather than treating it as a problem to solve after launch.

A development team might decide that sensitive information should never be stored in ordinary application logs. It could also restrict which services can access user profiles and establish automatic deletion periods.

The idea is straightforward: privacy should be part of the architecture, not an optional setting added at the end.

3. User-Controlled Personalization

Users should be able to decide which preferences an AI system remembers.

For example, an assistant could let someone save their preferred language and writing style while keeping other conversations temporary.

Clear controls should make it possible to review stored preferences, change them, or disable personalization.

This gives people a way to benefit from personalized AI experiences without surrendering control over every detail.

4. Anonymization and Pseudonymization

These terms are related, but they do not mean the same thing.

Anonymization attempts to remove the ability to connect information to an identifiable person.

Pseudonymization replaces direct identifiers, such as names, with alternative values. Additional information may still make it possible to reconnect the data to the individual.

For example, a customer dataset might replace names with random reference numbers while keeping the identity mapping in a separately protected location.

Pseudonymization reduces exposure, but it does not make the information automatically anonymous.

The European Data Protection Board explains this distinction in its anonymization and pseudonymization guidance. Its 2026 anonymization guidelines are currently open for public consultation, so they should be understood as draft guidance rather than final binding requirements.

5. On-Device Processing

Some personalization tasks can happen directly on a user's device instead of sending all relevant information to a remote server.

For example, a keyboard may learn commonly used words locally to improve suggestions.

This can reduce the amount of personal information transmitted to external services.

However, on-device processing is not automatically private. Devices still need appropriate security, and information may be synchronized or transmitted through other features.

6. Federated Learning

Federated learning allows a machine-learning model to learn from decentralized data without requiring every raw data record to be collected in one central location.

In a simplified example, a model can be updated using information processed on participating devices, while updates rather than raw examples are sent for aggregation.

This can reduce direct exposure of personal data, although model updates may still reveal information if the system lacks additional safeguards.

Google Research's October 2026 publication describes a federated-learning system with externally verifiable privacy guarantees and discusses differential privacy and secure aggregation as part of its approach.

7. Clear Data Retention Policies

Personal information should not remain stored indefinitely simply because storage is inexpensive.

A service should define how long different categories of information are needed and delete or appropriately de-identify them when the purpose has ended, subject to applicable legal and operational requirements.

Temporary conversation context, saved preferences, account information, and security logs may all need different retention periods.

No single privacy technique solves every problem. Effective privacy-focused AI combines appropriate technology with clear policies, access restrictions, and meaningful user control.

What Businesses and Developers Should Do Differently

Businesses often focus on what AI can accomplish: faster customer support, more relevant recommendations, and better automation.

But the data decisions behind those features deserve equal attention.

Responsible AI development means asking not only whether a feature works, but also whether it handles personal information appropriately.

Collect Only What the Feature Needs
Before building an AI feature, developers should identify its actual data requirements.

If a recommendation system needs a user's selected interests, collecting their entire browsing history may be unnecessary.

A useful design question is: would this feature still work if the system collected less information?

If the answer is yes, the additional collection needs a clear justification.

Explain Data Collection Clearly

Privacy notices should describe what information is collected, why it is needed, how it is used, and whether it is shared with other providers.

These explanations should be understandable without requiring users to interpret complicated technical language.

Businesses should also distinguish between information needed to deliver a service and information used for optional personalization.

Obtain Meaningful Consent

Consent should be informed and relevant to the activity.

A user who agrees to receive personalized recommendations should not automatically be treated as having agreed to unrelated uses of their personal information.

Where applicable, users should be able to change their choices without losing access to unrelated core features.

Secure Stored Information

Appropriate security controls include encryption, access restrictions, authentication, secure credential management, and regular testing.

Sensitive information should not be available to every employee, application component, or third-party service.

Access should be limited according to actual responsibilities.

Review Third-Party AI Services

Businesses frequently integrate external AI APIs, analytics tools, cloud platforms, and customer-support services.

Before sending personal information to these systems, organizations should understand their data-handling terms, retention practices, security controls, and permitted uses.

A privacy policy on a company's website cannot compensate for an uncontrolled data-sharing arrangement with an external provider.

Test Privacy Risks Before Deployment

Privacy reviews should be part of development and testing.

Teams can examine whether sensitive information appears in logs, whether access controls work as intended, whether user deletion requests are handled correctly, and whether information is exposed through unexpected application behavior.

The NIST AI Risk Management Framework provides a voluntary structure for identifying and managing AI risks across design, development, deployment, and evaluation. The OECD's AI principles also emphasize privacy, transparency, security, and accountability.

The practical lesson is that privacy should be tested like any other important system requirement.

What Users Can Do to Protect Their Personal Data

Businesses and developers carry significant responsibility, but users can also make more informed choices about how they interact with AI tools.

A few practical habits can help.

Avoid sharing highly sensitive information: Do not enter passwords, authentication codes, full financial details, or confidential documents into an AI tool unless there is a clear, trusted reason and suitable protection.
Review privacy settings: Check whether the service offers controls for conversation history, saved preferences, personalization, or use of submitted content.
Understand data handling: Read the provider's privacy information to understand how conversations and uploaded files are processed and retained.
Limit connected applications: Connect only the accounts and services needed for the feature you want to use.
Review permissions: Check whether an application still needs access to your location, contacts, files, or microphone.
Separate personal and professional information: Be especially careful when using consumer AI tools for confidential business material or customer records.

One more point matters: deleting a conversation from the visible interface does not necessarily mean every associated copy, backup, or retained record has immediately disappeared. The provider's actual deletion and retention policy determines what happens next.

The goal is not to become suspicious of every AI feature. It is to understand what information a service needs and make choices accordingly.

The Future of AI: Smarter Experiences, Stronger Privacy

AI personalization will likely become more context-aware as systems improve their ability to understand conversations, recognize patterns, and work across connected applications.

That could make digital services more useful.

An assistant might understand a user's preferred workflow, a learning platform might adapt lessons to individual progress, and a customer-support system might resolve problems with fewer repeated questions.

But better personalization does not have to mean unlimited data collection.

Privacy-enhancing technologies, local processing, federated learning, stronger security controls, and transparent data policies provide ways to develop useful AI systems while reducing unnecessary exposure.

There is also a growing need to evaluate how systems use information after collecting it.

A service might have a legitimate reason to remember a preference today, but that does not automatically justify retaining it forever or using it for a completely different purpose later.

The OECD AI Principles, updated in 2024, place privacy and data protection alongside fairness, transparency, robustness, and accountability as important elements of trustworthy AI.

Ultimately, the future of personalization should be measured not only by how accurately AI predicts what someone wants, but also by how well it respects what that person chooses to keep private.

Conclusion: AI Should Understand Your Needs, Not Own Your Information

AI personalization can make everyday digital experiences easier, faster, and more relevant.

Remembering a preferred language, understanding a recurring task, or recommending useful content can genuinely improve the way people interact with technology.

But usefulness should not become an excuse for collecting information without limits.

AI privacy should be considered throughout the entire process: what data is collected, why it is needed, who can access it, how long it is retained, and whether users have meaningful control.

For developers and businesses, that means building privacy into system architecture rather than treating it as an afterthought. For users, it means understanding what they share and making informed decisions about connected services.

The most useful AI will not necessarily be the system that knows the most about someone.

It will be the one that understands what matters, uses only the information it needs, and respects everything else.

If AI can make your life easier by knowing more about you, where should you draw the line?

Frequently Asked Questions

1. How does AI collect and use personal data?

AI systems may use information supplied directly by users, such as conversations and preferences, alongside activity data such as searches, clicks, purchases, and interactions. Depending on the service, this information can help generate recommendations, adapt responses, or predict what users may find useful.

2. What are the biggest AI privacy concerns?

Major concerns include unauthorized access, excessive data collection, unexpected sharing, sensitive information being inferred from behavior, and personal data being retained longer than necessary. Another concern is profiling, where information about someone's behavior influences recommendations or decisions without sufficient transparency.

3. Can AI personalization put personal information at risk?

Yes. Personalization may require storing or processing information about preferences, behavior, and previous interactions. If that information is poorly protected, shared unexpectedly, or used for unrelated purposes, it can create privacy and security risks. Appropriate access controls and data minimization help reduce exposure.

4. How can users protect their data when using AI tools?

Users should avoid sharing passwords, authentication codes, and unnecessary sensitive information. They should review privacy settings, understand conversation-retention policies, limit connected applications, and check what permissions an AI service requests before using its features.

5. Can AI provide personalized experiences without collecting excessive personal data?

Yes. Systems can use limited preferences, temporary context, on-device processing, and privacy-enhancing techniques such as federated learning and differential privacy. These approaches have different limitations, but they can help provide useful personalization while reducing unnecessary access to personal information.

The article uses official and research-based sources, linked contextually throughout the text.

[OC] I built a free, open-source HIPAA DICOM anonymizer for medical imaging

Fri, 30 Oct 2026 10:49:57 +0000

I just released dicom-clean — an open-source CLI tool for HIPAA-compliant DICOM de-identification. Here's how it works and why I built it.

The Problem

Medical imaging files (CT scans, MRIs, X-rays) use a format called DICOM, which contains two things:

Metadata — patient name, birth date, MRN, hospital, referring physician, etc.
Pixel data — the actual image

When hospitals want to share DICOM data for research, AI training, or vendor evaluation, they must remove the patient identifiers first — this is required by HIPAA Safe Harbor (45 CFR §164.514(b)(2)).

But existing options are problematic:

Commercial tools (RSNA CTP, DicomCleaner) cost $5,000+/year
Cloud solutions upload patient data → HIPAA violation risk
DCMTK / GDCM work but have steep learning curves (C++ toolchain, complex syntax)

So I built dicom-clean to be:

✅ 100% offline (air-gapped compatible)
✅ Simple CLI (one command)
✅ Zero-install (standalone .exe)
✅ Free and open source (AGPL-3.0)

What It Does

1. Strips All 18 HIPAA Patient Identifiers

The tool blanks out 40+ scalar PHI tags and deletes 8 sequences that may carry nested PHI:

HIPAA_TAGS_TO_BLANK = (
    (0x0010, 0x0010),  # PatientName
    (0x0010, 0x0020),  # PatientID
    (0x0010, 0x0030),  # PatientBirthDate
    (0x0010, 0x1040),  # PatientAddress
    (0x0008, 0x0080),  # InstitutionName
    (0x0008, 0x0090),  # ReferringPhysicianName
    # ... 40+ more
)

HIPAA_TAGS_TO_REMOVE = (
    (0x0008, 0x1110),  # ReferencedStudySequence
    (0x0008, 0x1115),  # ReferencedSeriesSequence
    # ... 6 more
)

Design decision: I blank the scalar tags (preserving tag + VR) rather than deleting them, so downstream PACS and DICOM viewers don't break when they expect those fields.

2. Deterministic UID Pseudonymization

DICOM uses UIDs (Unique Identifiers) to link files together. A study has a StudyInstanceUID, each series has a SeriesInstanceUID, and each image has a SOPInstanceUID.

If you just replace these with random UUIDs, you lose the relationships between files — a PACS server won't be able to group images from the same study.

My solution: SHA-256 with an optional salt.

def pseudonymize_uid(original_uid: str, salt: str = "") -> str:
    """Deterministically pseudonymize a DICOM UID."""
    if not original_uid:
        return original_uid
    digest = hashlib.sha256(
        (salt + str(original_uid)).encode("utf-8")
    ).hexdigest()
    number = int(digest[:32], 16)  # 128 bits
    return f"2.25.{number}"

Why this works:

Deterministic — Same input + salt → same output, always
Reversible relationships — All files from one study get consistent pseudonyms
Non-reversible — Without the salt, you can't reverse it
Valid format — Output is a proper DICOM UID (2.25.<128-bit-int>)

3. Image Integrity

The pixel data is never touched. Same for:

Modality (CT, MR, US, etc.)
PixelData
TransferSyntaxUID
PhotometricInterpretation
Rows / Columns
BitsAllocated / BitsStored
PixelSpacing / SliceThickness
Window/Level tags

So the image looks identical in any DICOM viewer — only the metadata changes.

4. Date Reduction

HIPAA permits keeping the year but not the month/day. So:

Before: StudyDate = "20250315"
After:  StudyDate = "20250101"

Tech Stack

Component	Purpose
pydicom	DICOM parsing & writing
Typer	CLI framework
Rich	Terminal UI (panels, progress bars, tables)
PyInstaller	Standalone `.exe` build

What It Looks Like

$ dicom-clean sanitize patient.dcm output\ --salt "my-secret"

The output shows a live progress bar and a colored summary table:

Total Files Scanned: 1,250
Successfully Anonymized: 1,248
Skipped (Non-DICOM): 2
Errors / Failed: 0

Directory Batch Processing

The tool recursively processes directories and preserves the original subfolder structure:

$ dicom-clean sanitize C:\Hospital_Data C:\Clean_Output --salt "hospital-2025"

Robustness

Non-DICOM files are skipped with a warning instead of crashing
Per-file errors are collected into a summary
Uses try/except for InvalidDicomError, OSError, IOError, and generic exceptions
Exit code 1 if any file failed, 0 otherwise

Installation

Windows Standalone (No Python Required)

Download dicom-clean.exe from the Releases page and run:

dicom-clean.exe sanitize input.dcm output\ --salt "my-secret"

From Source

git clone https://github.com/kaveen-ai/dicom-clean.git
cd dicom-clean
pip install -r requirements.txt
python anonymizer.py --help

Design Tradeoffs

Some decisions I made and why:

1. SHA-256 hashing vs random UUIDs for UIDs

✅ Hash preserves relationships across files
✅ Deterministic (reproducible)
❌ Requires salt management for security

2. Blank tags vs delete tags

✅ Blanking preserves tag structure (PACS-safe)
✅ Downstream tools don't break
❌ Leaves an empty tag with metadata footprint

3. AGPL-3.0 + Commercial dual-license

✅ Free for open-source use
✅ Commercial license funds development
❌ AGPL can be a dealbreaker for some hospitals

4. Single-file CLI vs library-first

✅ Standalone .exe for non-technical users
✅ The core DicomAnonymizer class is importable as a library
✅ CLI is just a thin Typer wrapper

The `DicomAnonymizer` Class

If you want to use the engine programmatically:

from anonymizer import DicomAnonymizer

anonymizer = DicomAnonymizer(
    salt="my-hospital-secret",
    remove_private_tags=True,
    reduce_dates_to_year=True,
)

summary = anonymizer.anonymize(
    input_path="patient.dcm",
    output_path="output/",
)

print(f"Anonymized {summary.anonymized} files")

The class handles:

UID pseudonymization
HIPAA tag blanking
Private tag removal
Date reduction
File meta sanitization

What's Next

I'm planning:

GitHub Actions CI — test matrix across Python 3.10-3.13
PyPI publication — pip install dicom-clean
Docker image — for hospital IT deployments
Pixel OCR redaction — for burned-in PHI in images (commercial edition)

Feedback Welcome

I'd love feedback from anyone working with DICOM data, healthcare IT, or medical imaging.

Star on GitHub: github.com/kaveen-ai/dicom-clean
Report bugs: Issues
Discussions: GitHub Discussions

What would you like to see next?

Tags: python healthcare opensource dicom privacy

Aribito: A Library That Points Before It Speaks

Fri, 30 Oct 2026 10:48:59 +0000

In my first Aribito article, I described a small local CLI experiment: three attributed perspectives on one request, followed by a human choice or a decision to hold. The choice is recorded; it does not execute the suggestion.

That raised another design question for me. If an AI team is going to help someone choose a next step, how should it find relevant project material without treating every search result as an instruction?

I am exploring a library index for that purpose. It is a proposal, not a feature of the current Aribito demo. The idea is to keep original documents where they belong and give the assistant a small card describing each document: an ID, kind, title, subjects, short summary, reference, and what is known about its freshness and verification. In the example below, the invented cards contain no source text.

A card is a lead, not an answer

Suppose someone asks, “Where is the guide for the prototype?” A matching card can say that a demo guide may be relevant. It cannot establish that the guide is current, that its contents are correct, or that the assistant may quote, send, or act on it. Those are separate checks.

Retrieval systems can quietly blur finding a document, reading it, trusting it, and doing what it says. The card's own summary deserves caution too: it could be mistaken, stale, or contain an instruction someone placed there. Even a top hit marked unverified is still unverified.

Here is a runnable illustration, using invented public project notes. It reads no files, calls no model, and has no connection to Aribito's current CLI. The demo: references deliberately resolve nowhere.

"""Illustrative, self-contained index example for this article.

Uses fabricated metadata. It does not read source files or connect to Aribito.
"""

from dataclasses import asdict, dataclass
from typing import Literal


SourceKind = Literal["project_note", "demo_guide", "role_outline"]
Freshness = Literal["current", "stale", "unknown"]
Verification = Literal["checked", "unverified"]


@dataclass(frozen=True)
class IndexEntry:
    entry_id: str
    source_kind: SourceKind
    canonical_ref: str  # Opaque demo reference, never a local file path.
    title: str
    logical_day: int | None
    subjects: tuple[str, ...]
    summary: str
    sensitivity: Literal["public", "restricted"]
    freshness: Freshness
    verification_status: Verification
    content_included: Literal[False] = False


def find_candidates(entries: tuple[IndexEntry, ...], term: str) -> tuple[IndexEntry, ...]:
    """Find metadata matches; a match is not evidence or permission."""
    needle = term.strip().casefold()
    if not needle:
        return ()
    return tuple(
        entry
        for entry in entries
        if entry.sensitivity == "public"
        and needle in " ".join((entry.title, *entry.subjects, entry.summary)).casefold()
    )


if __name__ == "__main__":
    # All three records are invented; these references resolve nowhere.
    fixture = (
        IndexEntry("demo-note-1", "project_note", "demo:note:1",
                   "Prototype project note", 12, ("prototype",),
                   "A sample project note exists.", "public", "unknown", "unverified"),
        IndexEntry("demo-guide-1", "demo_guide", "demo:guide:1",
                   "Prototype demo guide", 12, ("prototype",),
                   "A sample demonstration guide exists.", "public", "unknown", "unverified"),
        IndexEntry("demo-role-1", "role_outline", "demo:role:1",
                   "Public role outline", None, ("roles",),
                   "A sample public role outline exists.", "public", "unknown", "unverified"),
    )
    for candidate in find_candidates(fixture, "prototype"):
        print(asdict(candidate))

Run it with python aribito_library_index_example.py. The two printed records are candidates for “prototype.” Both still say freshness='unknown' and verification_status='unverified'. The toy function excludes records without a public label; that condition alone is not an access-control policy for real sources.

What I would test next

The code demonstrates only metadata lookup. It searches the summary as text, but never treats that text as a command or verifies it. Before a real assistant used an index, I would want to test whether it keeps these questions separate:

Did the lookup find a candidate document?
Was the original document actually read, and when?
Is the specific claim supported by that document?
Is the requested use of the information authorized?

A possible later handoff would pass a candidate reference to a separately bounded reader. That reader would need to report whether it actually opened the source and which claim it supports; permission to reveal or act on the result would be checked separately. This handoff has not been built or tested. The type hint Literal[False] does not enforce the field at runtime, and a summary could itself expose source content. A real index would need validation and review before exposing cards.

For me, the promising part of a library is modest: it can help an AI team say, “Here is where we might look, and here is what we still do not know.” That seems like a better starting point than letting a search hit speak with the authority of the original source.

What metadata would you want to see before trusting an assistant's suggested source?

Direction and publication decision: Masato Kato. Structure, prose, and illustrative code: Codex editorial assistance. The example contains invented metadata and is not a live model transcript or a claim about deployed Aribito behavior.

From Writing the Spec to Approving It: What AI-DLC Looks Like on a Real Build

Fri, 30 Oct 2026 10:36:49 +0000

🤖 From Writing the Spec to Approving It: What AI-DLC Looks Like on a Real Build

TL;DR

AI-DLC is public and open source: awslabs/aidlc-workflows. The method comes from this AWS DevOps blog post.

My only written input was one sentence. Everything else I did was pick options and approve gates.

The run produced requirements, four architecture decisions, a unit plan, a traceability file, and 12 tests that passed when I ran them, in about 44 minutes from start to the code approval.

The human role moves from author to decision-maker. The decisions are still yours, and the record shows where they changed the outcome.

Most AI-assisted development still follows the old split. A human writes the spec, a human writes the code, and the AI helps with autocomplete or generates tests at the end. AI-DLC (the AI-Driven Development Life Cycle) reverses that. The AI drafts the requirements, the design, and the code. The human answers short questions and approves each stage before the next one starts.

To see what that looks like in practice, I built a small command-line tool with it and then read the record the workflow left behind. This post walks through that record, folder by folder.

The app

The tool is a Spooky Date Fact Generator. It picks one of 10 spooky dates (or takes --date MM-DD) and prints a spooky event for that day from Wikipedia's "On this day" feed. It is small on purpose.

The whole request was this sentence:

/aidlc build random date generator with fact around that number

The flip, in one table

	Traditional with AI help	AI-DLC
Requirements	Human writes them	AI drafts them from multiple-choice answers
Design	Human sketches it	AI proposes, human picks between options
Code	Human writes, AI assists	AI writes against an approved plan
Tests	Human or AI at the end	AI writes them to the stated requirements
Human job	Author	Decide, validate, approve
Evidence	Pull request diff	Audit log, decisions, traceability file

Where everything was written

Two locations matter. The generated app sits in its own folder, and the workflow record sits in an aidlc/ folder.

app/                                  <- the generated tool
  src/spooky-facts.ts      core: dates, fetch, keyword filter, nearest-date search
  src/cli.ts               command line: options, output, exit codes
  test/                    12 tests, offline, with a fake fetch
  package.json, biome.json, tsconfig.json, README.md

aidlc/
  codekb/                             <- 9 docs about the existing repo
  intents/<date>-date-fact-generator/ <- the record for this build
    aidlc-state.md                    stage checklist and settings
    audit/                            every event, decision, and approval
    inception/
      reverse-engineering/            scan of the existing repo
      requirements-analysis/          questions + requirements.md
      domain-design/                  questions + components.md + decisions.md
      units-generation/               unit-of-work files
    construction/u1-spooky-date-cli/code-generation/
      code-generation-plan.md, code-summary.md,
      unit-test-instructions.md, traceability.json

Each stage writes a -questions.md file, and your answers sit in the same file as the AI's questions. That makes the decision trail readable without any tooling.

Stage by stage: what it did and why it helps

Initialization. The workflow scaffolded the record folder, scanned the workspace, and classified it as brownfield TypeScript on Bun. This is automatic. It helps because every later stage starts from facts about the repo instead of guesses.

Reverse Engineering. A developer agent scanned the existing repo and wrote nine knowledge-base documents (architecture, technology stack, code structure and others). This matters most in a brownfield repo. The later code followed the repo's Bun, TypeScript, and Biome conventions because the AI had read them first.

Requirements Analysis. The AI asked six questions, such as where facts come from, what to do when a date has no spooky event, and whether this should be a web page or a command line. Each had lettered options. I answered, and one answer included a free-text note: generate dates that have spooky facts, from 10 such scenarios. The result is requirements.md with 15 functional and 5 non-functional requirements, each with acceptance criteria and a tag pointing back to the answer that produced it, such as [Q5]. This stage turns one vague sentence into testable statements before any code exists.

Domain Design. Four more questions produced components.md and four architecture decision records. The AI recommended splitting the tool into four parts. I chose two. The decision record states that the four-part split was rejected as more structure than needed. This is the clearest example of the validator role, because the human overrode the AI's recommendation and the reason is recorded.

Units Generation. One question: build as one unit or two. I chose one, approved the plan, and got unit-of-work.md with boundaries, responsibilities, and constraints. It fixes the blast radius. The unit is limited to apps/date-fact-generator/, and nothing in the framework folders may change.

Code Generation. The AI wrote a plan, then the code, then the tests. It asked one thing here: Bun was not installed, so should it install Bun or switch to Node. I chose Bun. The code-summary.md lists files created, decisions made, and deviations from the plan. One deviation worth noting: the AI added word forms such as "dies" and "sank" to the keyword list, because whole-word matching would otherwise miss "Houdini dies". The summary also states that some planned checks were grouped into fewer tests to match the 12-test count.

Build and Test. In the record I read, this stage was still marked in progress, so its summary was not written yet. I ran the checks myself from the app folder: 12 tests passed with 93 assertions, and lint and typecheck were clean.

What the human actually did

Reading the audit log, the human work was this:

Typed one sentence to start.
Approved a recomposed plan. The workflow's planner found the default express plan was missing inputs for later stages, and proposed adding Domain Design and Units Generation while dropping deployment and monitoring.
Answered 11 multiple-choice questions across three stages, plus two more decisions: build inside the existing repo, and install Bun.
Approved 5 stage gates: reverse engineering, requirements, domain design, units, and code generation.

That is the flip. Nothing in that list is writing a spec or writing code. All of it is deciding and checking.

Why this holds up better than a prompt

Two details make the validation real instead of a rubber stamp.

First, traceability. traceability.json maps every requirement ID (FR1.1 through NFR5, 20 in total) to the file that satisfies it. If a requirement has no target, it shows up.

Second, the record is complete. The audit log holds the timestamp of each question, answer, and approval. A reviewer six months later can see why the design has two components and not four.

What this run does not show

This was an express-scope build of a 658-line app, with plan approval, sensors, and learnings switched off by the scope. It shows the shape of the method, not how it behaves on a large system with many units and teams. The Build and Test stage had not completed in the record, and the tests are offline, so only one manual live smoke run, recorded in the code summary, exercised the real Wikipedia feed.

The questions are only as good as the options offered. A weak option list can steer a hurried approver, so reading the alternatives still matters.

Takeaway

The useful change is not that the AI writes more code. It is that the human's time moves to the points where judgment counts: what the tool should do, which design to accept, and whether the result meets the requirements. If you want to try it, start with a small brownfield repo and read the -questions.md files first. They show the method faster than any description.

How Organizational Structure Dictates Software Design: Understanding Conway's Law

Fri, 30 Oct 2026 10:28:18 +0000

What is Conway's Law?

Conway's Law is an influential observation made by computer programmer Melvin Conway in 1967. It states that organizations which design software systems are bound to produce designs that copy the communication structures of those organizations. In simpler terms, the way your company's teams are structured and communicate directly dictates how your codebase is organized and how different modules interact.

A Real-World Analogy: City Infrastructure

Imagine a city planning department split into three isolated teams: the Road Department, the Water Department, and the Electricity Department. Instead of sitting together to plan a street, the Road Department builds a freshly paved highway. A month later, the Water Department tears up the new asphalt to lay down water pipes because they never coordinated. Finally, the Electricity Department digs up the street again to bury power cables.

Because the teams operated in strict isolation, the final street structure becomes a chaotic, patched-up mess with redundant dig sites. Had the city restructured these workers into a single neighborhood planning squad, the street, pipes, and cables would have been laid smoothly in one unified pass.

Why Conway's Law Matters in Daily Tech Operations

In software engineering, Conway's Law manifests every day in system architecture, API boundaries, and technical debt. When leadership divides engineering strictly by technical layers—such as a dedicated React frontend team, a Node.js backend team, and a MySQL database administration team—the resulting software predictably develops rigid, overly complex network boundaries between those layers.

Developers spend endless hours writing boilerplate translation code, serializing JSON payloads back and forth, and waiting on pull request approvals across organizational boundaries. Conversely, when companies form cross-functional "feature teams" aligned around business domains (like Checkout or User Auth), the codebase naturally evolves into clean, modular services or domain-driven modules. Understanding this law prevents software architects from fighting against their company’s org chart and helps managers restructure teams to achieve better technical designs.

Concrete Scenario: E-Commerce Team Restructuring

Before (Siloed Teams)

An e-commerce platform is built by three separate departments: a React UI team, an Express.js API team, and a MySQL DBA team.

To display a user's account dashboard, the React frontend must make three separate HTTP requests to the Express server (/api/users, /api/user-permissions, and /api/user-cart) because three different backend sub-teams created those routes independently. Furthermore, the Express API requires complex DTO (Data Transfer Object) mapping because the database team maintains a legacy MySQL schema and requires formal ticket submissions for schema modifications.

Result: High network latency, duplicated state management in React, and heavy database query bloat.

After (Domain-Driven Feature Team)

The organization restructures into a cross-functional "Checkout Domain Team" containing a React engineer, a Node.js developer, and a MySQL expert working side-by-side.

The team simplifies the API down to a single optimized Express route (GET /api/dashboard). The Express endpoint executes a streamlined SQL query using MySQL JOIN statements, returning all required dashboard data in a single payload. The team deploys updates together without inter-departmental bureaucracy.

Key Takeaway

You cannot fix a messy software architecture purely with code refactoring if your team structure enforces the mess. If you want modular, loosely coupled, and maintainable software, you must first design loosely coupled, clear, and collaborative team communication channels.

Enjoyed this breakdown? Support my open-source work on Buy Me a Coffee or explore react-hook-lab!

Originally published on my blog. You can read the alternative breakdown here.

Coder Legion - Recent posts

Trust But Verify: My Solo Developer AI Agent Workflow for Shipping Without Regrets

Trust But Verify: My Solo Developer AI Agent Workflow for Shipping Without Regrets

Why I Stopped Trusting the Word "Done"

The Solo Developer AI Agent Workflow, in Five Steps

Step 1 — Write a brief a stranger could follow

Step 2 — Build small, in one direction

Step 3 — Verify against the live system, never the report

Step 4 — Ship in batches, on a schedule I control

Step 5 — Log it, or it never happened

The Green Test Suite That Wasn't

Solo Developer AI Agent Workflow: The Verification Checklist

What the Human Gate Is Actually For

The Bottom Line

AI Lesson Planning for Teachers: How I Cut Prep Time in Half Without Losing the Human Touch

AI Lesson Planning for Teachers: How I Cut Prep Time in Half Without Losing the Human Touch

What AI Lesson Planning for Teachers Actually Looks Like in a Real Classroom

My 30-Minute AI Lesson Planning Workflow

The Prompt Pattern That Keeps Lessons Honest

AI Lesson Planning for Teachers: The Guardrails I Never Skip

A Real Example: One Lesson, Before and After

Your First-Week Checklist

The Bottom Line

Sovereign Intelligence or Perpetual Rental (Volume III): The Global South Compute Bank (GSCB)

Read the full paper

Sovereign Land Banking in the Bengal Delta: Khas Land, Private Equity Leasehold, Transit Value Captu

Read the full paper

Sovereign Land Banking in South Asia: Legal Genealogy, Title Mechanics, Financial Architecture and A

Read the full paper

EnNode Gateway – Smart BACnet and Modbus Integration

How to Connect BACnet and Modbus Devices in a Building Management System

The Challenge of Connecting Different Devices

How Does a Protocol Gateway Help?

Introducing the EnNode Gateway

A Practical Example: Integrating an Energy Meter into a BMS

Where Can This Gateway Be Useful?

Final Thoughts

Python for commerce students, from a former bio kid

The other side of the room

Why Python, if you already have Excel

You don't even need to install anything

A beginner path, from spreadsheet to pandas

Free resources I'd point people to

Being at the front of the room

FAQ

Do commerce students need to learn coding?

Is this financial advice?

What's the fastest way to start?

Sources

What next

Your Tests Are Green and Prove Nothing: 4 Signs You're Testing the Mock

1. You Mocked the Thing You Are Testing

2. You Assert the Calls, Not the Outcome

3. The Fake Database Only Says Yes

4. Snapshots Approved Without Reading

The 60-Second Sabotage Check

What to Mock, and What Not To

The Rule

How to Change the WAF Web Console Listening Port When SafeLine Stays on 9443

The misconfiguration

What to compare before you call it a port change

The screen that confirms the fix

What this check does not claim

Why does the console still open on 9443 after I edited the environment file?

Is the application port the same as the web console port?

What does MGT_PROXY change if it is not the listen port?

Which screen confirms the console port is the one I intended?

Do I need a new administrator password after correcting the port?

Why I Change the WAF Web Console Listening Port Before Turning Protection On

Set the console port before the first launch

Keep that port off the public site path

Clear the host, secrets, and login gates

Name the protection you are actually turning on

How do I change the WAF web console listening port?

Is the web console port the same as the application listen port?

What should I verify before I turn protection on?

Does a different console port require MGT_PROXY?

How do I know the protection decision worked?

How to Reset the WAF Admin Account Inside Docker

What was misconfigured