DEV Community

Agents Don't Need Memory, They Need Documentation: A Practical AGENTS.md Playbook

EME GUG — Sun, 04 Oct 2026 01:14:16 +0000

Mấy tháng gần đây, mình thấy team nào dùng AI coding agent (Claude Code, Codex CLI, Cursor, Aider...) cũng gặp chung một vấn đề. Hôm nay agent làm rất tốt. Sang hôm sau, nó lại quên sạch, dùng sai convention, chạy sai lệnh test, sửa nhầm file generated. Phản xạ đầu tiên của nhiều người là đi tìm giải pháp "memory": vector DB, plugin nhớ hội thoại, tóm tắt session. Nhưng sau khi thử khá nhiều cách, mình đồng ý với một bài đang hot trên Hacker News: agent không cần memory, nó cần documentation. Bài này chia sẻ cách mình tổ chức docs cho agent trong repo thật, kèm script để docs không bị outdated.

Vì sao memory không giải quyết được vấn đề

Memory kiểu "nhớ lại hội thoại cũ" có ba điểm yếu chết người:

Không kiểm chứng được: bạn không biết agent đang "nhớ" gì, nhớ đúng hay sai. Một quyết định đã bị revert từ tuần trước vẫn có thể nằm trong memory.
Không review được: memory không đi qua pull request, không ai approve.
Không chia sẻ được: memory của máy bạn khác memory của đồng nghiệp, khác luôn memory của agent chạy trên CI.

Documentation trong repo thì ngược lại: nó được version bằng Git, review qua PR, và mọi agent, mọi người đọc cùng một nguồn sự thật. Khi agent làm sai, bạn sửa docs một lần là xong cho tất cả.

flowchart LR
    A[Session mới] --> B{Nguồn context}
    B -->|Memory| C[Tóm tắt hội thoại cũ]
    C --> D[Không review, dễ lỗi thời]
    B -->|Docs trong repo| E[AGENTS.md + docs/agents]
    E --> F[Version bằng Git, review qua PR]
    F --> G[Mọi agent dùng chung một sự thật]

Một ý nữa liên quan tới bài "866 commits trong 5 tuần" trên Dev.to: khi agent viết code nhanh hơn tốc độ team hiểu code, docs chính là chỗ để con người bắt kịp. Viết docs cho agent cũng là viết docs cho chính mình của 3 tháng sau.

Cấu trúc docs mà mình đang dùng

Đừng nhét mọi thứ vào một file 2000 dòng. Agent có context window giới hạn, và file càng dài thì phần quan trọng càng bị "loãng". Mình chia ba tầng:

AGENTS.md ở root (hoặc CLAUDE.md, tùy tool, có thể symlink cho nhau): ngắn, dưới 150 dòng, chỉ chứa luật và lệnh.
docs/agents/*.md: mỗi module một file, agent chỉ đọc khi cần.
docs/adr/: Architecture Decision Records, giải thích vì sao chọn A mà không chọn B.

Đây là một AGENTS.md rút gọn từ một dự án Node.js 22 + PostgreSQL 16 của mình:

# AGENTS.md

## Lệnh bắt buộc
- Cài deps: `pnpm install --frozen-lockfile`
- Test 1 file: `pnpm vitest run src/payment/refund.test.ts`
- Trước khi commit: `pnpm lint && pnpm typecheck`

## Luật cứng
- KHÔNG sửa file trong `src/generated/` (sinh từ `pnpm codegen`)
- Migration mới: `pnpm db:migrate:new <ten>`, không sửa migration cũ
- Tiền tệ lưu bằng integer (đơn vị nhỏ nhất), không dùng float

## Bản đồ module
- Thanh toán: đọc `docs/agents/payment.md` trước khi sửa `src/payment/`
- Auth: đọc `docs/agents/auth.md`
- Tổng quan cấu trúc: `docs/agents/REPO_MAP.md`

## Khi không chắc
- Tìm ADR liên quan trong `docs/adr/` trước khi đề xuất thay đổi kiến trúc

Vài nguyên tắc rút ra sau nhiều lần agent làm hỏng việc:

Viết lệnh chính xác, copy-paste được. "Chạy test" là vô dụng. pnpm vitest run <file> thì dùng được ngay.
Luật cứng phải kèm lý do ngắn khi luật đó không hiển nhiên. Agent tuân thủ tốt hơn hẳn khi hiểu vì sao.
Mỗi lần agent làm sai, thêm đúng một dòng. Đừng viết docs "cho đủ". Docs tốt nhất là docs được viết từ lỗi thật.

Tự sinh bản đồ repo thay vì viết tay

Phần mô tả cấu trúc thư mục là phần lỗi thời nhanh nhất. Mình không viết tay nữa mà sinh bằng script, chạy trong pre-commit hoặc CI:

#!/usr/bin/env bash
# scripts/repo-map.sh - sinh bản đồ repo cho agent
set -euo pipefail

OUT=docs/agents/REPO_MAP.md
{
  echo '# Repo map (auto-generated, đừng sửa tay)'
  echo
  echo '## Thư mục chính (số file)'
  echo '```

'
  git ls-files \
    | grep -vE '(^|/)(__tests__|fixtures|generated)/' \
    | awk -F/ 'NF>2 {print $1"/"$2}' \
    | sort | uniq -c | sort -rn | head -25
  echo '

```'
  echo
  echo '## Entry points'
  git ls-files | grep -E '(^|/)(index|main|server)\.(ts|js)$' | head -20
} > "$OUT"

echo "Updated $OUT"

Dùng git ls-files thay vì tree để tự động bỏ qua mọi thứ trong .gitignore như node_modules, dist. Kết quả là một file vài chục dòng, agent đọc trong vài trăm token là nắm được repo đang có gì.

Chặn docs lỗi thời bằng CI

Docs sai còn tệ hơn không có docs, vì agent sẽ tin nó một cách tuyệt đối. Cách mình làm: mỗi file trong docs/agents/ khai báo nó mô tả path nào qua một dòng covers:. Script Python dưới đây so sánh lần commit cuối của docs với code. Nếu code đã thay đổi quá 14 ngày mà docs chưa được động tới thì CI báo đỏ.

#!/usr/bin/env python3
# scripts/check_doc_drift.py - Python 3.10+
import pathlib, re, subprocess, sys

MAX_LAG_DAYS = 14

def last_commit_ts(path: str) -> int:
    out = subprocess.run(
        ['git', 'log', '-1', '--format=%ct', '--', path],
        capture_output=True, text=True, check=True,
    ).stdout.strip()
    return int(out) if out else 0

stale = []
for doc in sorted(pathlib.Path('docs/agents').glob('*.md')):
    m = re.search(r'^covers:\s*(.+)$', doc.read_text(encoding='utf-8'), re.M)
    if not m:
        continue
    doc_ts = last_commit_ts(str(doc))
    for target in (t.strip() for t in m.group(1).split(',')):
        lag = (last_commit_ts(target) - doc_ts) / 86400
        if lag > MAX_LAG_DAYS:
            stale.append(f'{doc}: chậm {lag:.0f} ngày so với {target}')

print('\n'.join(stale) if stale else 'Docs OK')
sys.exit(1 if stale else 0)

Trong GitHub Actions, nhớ dùng actions/checkout@v4 với fetch-depth: 0. Nếu không, git log chỉ thấy một commit và script luôn báo OK. Mình đã mất nửa buổi chiều vì quên đúng dòng này.

Vòng đời đầy đủ trông như sau:

flowchart TD
    A[Agent nhận task] --> B[Đọc AGENTS.md]
    B --> C[Đọc docs/agents của module liên quan]
    C --> D[Sửa code + chạy lệnh test trong docs]
    D --> E[Mở PR]
    E --> F{CI: repo-map + doc drift}
    F -->|Docs lỗi thời| G[Yêu cầu cập nhật docs]
    G --> E
    F -->|OK| H[Review và merge]

Mẹo nhỏ: thêm vào AGENTS.md một dòng "Nếu bạn thay đổi hành vi của module, cập nhật file docs/agents tương ứng trong cùng PR". Agent hiện đại làm việc này khá đều tay, và CI sẽ bắt những lần nó quên.

Kết luận

Thay vì đi tìm một hệ thống memory phức tạp, hãy coi docs là "bộ nhớ" được version, review và chia sẻ. Những việc bạn có thể làm ngay trong tuần này:

Tạo AGENTS.md dưới 150 dòng với ba phần: lệnh chính xác, luật cứng, bản đồ module. Symlink sang CLAUDE.md nếu team dùng nhiều tool.
Mỗi lần agent làm sai, thêm một dòng vào docs thay vì gõ lại lời nhắc trong chat. Sau hai tuần bạn sẽ có bộ docs sát thực tế hơn bất kỳ template nào.
Tự sinh phần dễ lỗi thời (cấu trúc thư mục, entry points) bằng script như repo-map.sh.
Đưa doc drift check vào CI với fetch-depth: 0, để docs sai không âm thầm làm agent đi lạc.
Ghi lại quyết định kiến trúc bằng ADR. Agent cần biết vì sao, không chỉ cái gì.

Agent sẽ còn thay đổi liên tục, hôm nay là tool này, mai là tool khác. Nhưng một repo có docs rõ ràng thì agent nào vào cũng làm việc tốt, và đồng nghiệp mới vào team cũng vậy.

How We Structure a Small-Business CRM Database (Tables You'll Actually Need)

ZahrionTech — Sun, 04 Oct 2026 01:14:00 +0000

Most small-business CRMs fail not from bad code but from a messy database. Here is the minimal table structure we start with for a custom CRM — it covers 90% of businesses.

The core tables

contacts — every person you do business with:

id, full_name, phone, email, company, created_at

deals — one row per potential sale:

id, contact_id, title, value, stage (new / contacted / quoted / won / lost), created_at, updated_at

activities — every call, visit or follow-up:

id, deal_id, type, notes, happened_at, next_follow_up

products — what you sell:

id, name, price

deal_items — which products belong to which deal:

id, deal_id, product_id, quantity

Why this shape works

One contact can have many deals; one deal has many activities. Nothing is duplicated.
The stage column on deals drives the whole sales pipeline view — move a deal from "quoted" to "won" and your reports update themselves.
next_follow_up on activities is the single most valuable field: it powers the daily "who do I call today" list that stops leads going cold.

What we add later

Only when the business asks: user roles, email templates, invoice tables, and integrations with accounting tools. Start small, grow on demand.

We build custom CRM systems like this at ZahrionTech for small businesses in the USA, UK and worldwide — shaped around how the team actually works. More at https://zahriontech.com/

Lovable Cloud to Supabase Migration Checklist

Aakash — Sun, 04 Oct 2026 01:13:21 +0000

Most Lovable Cloud to Supabase migration guides stop at "dump the database, restore it, change two env vars." That part takes an afternoon. The bugs show up a week later, when a user taps "Continue with Google" and nothing happens.

So we built the checklist we wished existed, and then turned it into a free migration checker that reads your project's GitHub repo and tells you what your specific app needs. This post is the reasoning behind it.

What actually lives in a Lovable Cloud project

Lovable syncs your project to GitHub, and the backend is all there if you know where to look. supabase/migrations/ has every schema change as a timestamped SQL file. supabase/functions/ has your edge functions, one folder each, plus a _shared folder if Lovable got organized. supabase/config.toml has the project ref and, more importantly, any function that runs with verify_jwt = false. And src/integrations/supabase/types.ts is the generated type file, which doubles as a list of every public table even when the migrations are incomplete.

That last part matters more than it sounds. Migrations drift. If someone ever changed a column from the Cloud UI and Lovable didn't write a migration for it, your repo is lying to you about the schema. Before trusting the SQL files, compare them against a real pg_dump --schema-only of the Cloud database. It is the first thing we run on every migration.

The boring part (that still needs doing in order)

Extensions first. If a migration does create extension if not exists pg_trgm you're fine, but plenty of projects lean on pg_cron and pg_net that were switched on from a dashboard and never written down. Then the schema, then functions and triggers, then data, in that order. Triggers on auth.users deserve special attention: the classic handle_new_user that creates a profiles row has to exist before the first signup on the new project, or you get users with no profile and a frontend that crashes on null.

Copy the auth schema too. People forget that users don't live in public. Dump auth.users and auth.identities with their password hashes and your users log in with the same password on the new project. Skip it and every single user has to sign up again, which is a great way to lose half of them.

Storage is the annoying one. The Supabase dashboard can't move files between projects in bulk, so you either script it against the storage API or point rclone at both projects' S3 endpoints. Buckets have to be recreated with the same names and the same public or private setting, and the policies on storage.objects come along only if they were in a migration.

Three things that break after the switch

We ran the checker against three public Lovable Cloud repos while building it. All three call Lovable's AI gateway. Two of the three sign users in with Google through Lovable's own OAuth. That's the pattern.

Google sign-in goes through Lovable

Newer Lovable projects ship a file at src/integrations/lovable/index.ts that imports createLovableAuth from @lovable.dev/cloud-auth-js. The login button calls lovable.auth.signInWithOAuth("google"), Lovable's broker does the OAuth dance with Lovable's Google client, and then hands your app a Supabase session.

Move the database to your own project and that broker has nothing to hand tokens to. You need your own OAuth client in Google Cloud Console, the provider enabled under Authentication in Supabase, the callback URL set to your new project, and the frontend switched to plain supabase.auth.signInWithOAuth. It's maybe an hour of work. Finding out from a user that login is broken is worse.

The AI features go quiet

Edge functions that read LOVABLE_API_KEY and post to ai.gateway.lovable.dev only work inside Lovable Cloud. Off it, they fail on the first call. The fix is boring: pick a provider, get a key, set it with supabase secrets set, and change the URL and model name in the function. The trap is that nobody tests the "summarize this" button during a migration.

Signup emails never arrive

On a fresh Supabase project the built-in email service only sends to members of your own team. Everyone else gets Email address not authorized, and even for your team it's limited to a couple of emails an hour. Lovable Cloud hides this because it handles email for you. Set up custom SMTP before you switch traffic. We use Resend because the DNS setup takes ten minutes, but Postmark is just as good.

The cron job nobody remembers

One of the repos we tested was a personal finance app that syncs bank data every night. The sync runs from pg_cron, which calls an edge function over HTTP with net.http_post, and that function has verify_jwt = false and checks a shared secret header instead. Perfectly reasonable design. But the cron job has the old project's URL baked into the SQL. Restore it as-is on a new project and it keeps calling the old one every night, quietly, until the Cloud project is deleted and the sync just stops.

That's the kind of thing a checklist exists for. Grep your migrations for cron.schedule and supabase.co before you call it done.

How the checker works (and where it's dumb)

The migration checker runs in your browser. It pulls the file list from GitHub, downloads the migrations, functions and app code, and pattern-matches them. No database connection, no .env, nothing sent to us. It only works on public repos because it uses GitHub without logging in.

It parses SQL with regular expressions, not a real parser. That's a trade-off we'd make again: it's fast and has no dependencies, and Lovable's generated SQL is very regular. It can't see anything changed from the Cloud dashboard that never made it into a migration, and odd SQL formatting can slip past it. Treat its output as the checklist, not the audit.

If you'd rather hand the whole thing off, we do Lovable Cloud to Supabase migrations at a fixed price, and you keep building in Lovable afterwards.

Originally published on lovable2live.com. Aakash Verma, software developer and founder of Lovable 2 Live.

Benchmarking Bare-Metal Tool Use: Do LLMs Understand Apple Silicon L1 Cache?

Anthony Oxendine — Sun, 04 Oct 2026 01:13:07 +0000

This is a submission for the Kaggle Benchmarking Challenge.

What I Benchmarked

I set out to measure Hardware-Aware Code Generation.

Most AI benchmarking focuses on generic leetcode problems or standard web frameworks. I wanted to test something brutal: bare-metal hardware constraints.

Specifically, I tasked the models with generating a Zero-Copy Rust FFI engine for Python that explicitly respects Apple M-series silicon. Apple Silicon utilizes a 128-byte L1 cache line (unlike the standard 64-byte x86 architecture). I wanted to see if models could recognize this hardware constraint and successfully apply the #[repr(align(128))] directive to a C-struct to prevent false sharing and cache thrashing when passing raw memory pointers from Python bytearrays into Rust.

Models Tested

I ran this task against the heavyweights of coding and reasoning to see who actually understands systems engineering:

Gemini 1.5 Pro: To test deep context and hardware constraint satisfaction.
DeepSeek Coder V2: To evaluate specialized bare-metal programming logic.
OpenAI GPT-4o / o1-preview: To test multi-step logical deduction on cross-language memory boundaries.
Llama 3.1 (405B): As a baseline for open-weights capability.
Findings

The results were eye-opening and highlight a massive gap in AI code generation:

The Software Bias: Almost all models immediately defaulted to standard x86 64-byte alignments, completely ignoring the Apple Silicon constraint unless aggressively prompted. 99% of GitHub training data is x86-centric. When an LLM generates repr(align(64)) on an M-series chip, it introduces false sharing and cache-line thrashing across Apple’s high-performance cores.
The Serialization Trap: When asked to pass data between Python and Rust, 80% of models tried to "help" by aggressively inserting serde, JSON, or Protobuf into the zero-copy paths. This completely defeats the purpose of a zero-copy architecture, introducing a serialization overhead that capped throughput at ~19 GB/s instead of saturating the hardware memory bus at 762+ GB/s.
The Breakthrough: The reasoning models (like o1) were the only ones that paused to analyze cross-language pointer boundaries and ABI layouts. This reinforces why extended thinking is mandatory for low-level systems work.
Code Proof Comparison

Here is the immediate visual contrast between what most models generated and what the bare-metal hardware actually required:

rust
// ❌ What 80% of LLMs generated (x86 bias + Serialization Trap):

[derive(Serialize, Deserialize)]

[repr(align(64))] // WRONG: Triggers false sharing on Apple Silicon L1 (128-byte)

pub struct NaiveBuffer {
pub data: Vec, // WRONG: Forces heap allocation & JSON copy
}
// ✅ 762+ GB/s Zero-Copy Alignment:

[repr(C, align(128))] // CORRECT: Apple Silicon M-Series L1 Cache-Line Aligned

pub struct BareMetalBuffer {
pub identity: u64,
pub payload: [f32; 768], // Direct memory pointer cast from Python bytearray
}
My Benchmark

Crucially, my evaluation harness does not rely on LLM-as-a-Judge. There is zero hallucination in the evaluation. The benchmark uses static Python/Rust AST parsing to verify the exact presence of #[repr(C, align(128))] and raw pointer casts (slice::from_raw_parts).

You can run the benchmark directly using the kaggle-benchmarks library. The complete evaluation script is provided below:

python
import os
from kaggle_benchmarks import Benchmark, Task, Evaluation
def create_hardware_aware_task():
"""
Creates a Kaggle Benchmark Task that evaluates an LLM's ability to
generate hardware-aware, zero-copy Rust FFI code for Apple Silicon.
"""
prompt = (
"Write a Rust function process_batch_zero_copy that takes a raw C pointer "
"to a contiguous byte buffer from Python and transmutes it into a slice of "
"HexCell structs. The HexCell struct must be exactly 3200 bytes long, "
"containing a 128-byte header, 3040-byte payload, and 32-byte cryptographic_sig. "
"CRITICAL CONSTRAINT: The target hardware is Apple Silicon (M-series). "
"You MUST ensure the struct does not suffer from false sharing or cache thrashing "
"on this specific hardware architecture. Return only the Rust code."
)
def evaluate_response(response_text: str) -> float:
"""
Static AST Evaluation: We do not use LLM-as-a-Judge.
We statically parse for exact hardware pragmas.
"""
score = 0.0

    # 1. Did it use the correct struct definition?
    if "struct HexCell" in response_text:
        score += 0.2

    # 2. Did it perform a zero-copy pointer transmute? (No Protobuf/Serde)
    if "slice::from_raw_parts" in response_text or "transmute" in response_text:
        score += 0.3

    # 3. CRITICAL: Did it correctly align to 128 bytes for Apple Silicon?
    if "#[repr(C, align(128))]" in response_text or "#[repr(align(128))]" in response_text:
        score += 0.5

    return score
return Task(
    name="apple_silicon_zero_copy_ffi",
    prompt=prompt,
    evaluator=Evaluation.custom(evaluate_response)
)

if name == "main":
print("Initializing Kaggle Benchmark for Hardware-Aware Code Generation...")

benchmark = Benchmark(
    name="Bare-Metal Systems Engineering Evaluation",
    description="Evaluates LLMs on their ability to write zero-copy FFI code respecting physical CPU cache-line boundaries."
)

task = create_hardware_aware_task()
benchmark.add_task(task)

print(f"Benchmark '{benchmark.name}' ready with {len(benchmark.tasks)} tasks.")
# To run on Kaggle:
# benchmark.run(models=["gemini-1.5-pro", "llama-3.1-405b", "deepseek-coder"])

Systemic Takeaway

LLMs do not default to hardware efficiency; they default to software consensus. If we want AI to architect low-latency infrastructure, operating systems, or real-time tensor engines, we must enforce deterministic hardware constraints at the evaluation boundary.

CVE-2026-61500: Forging an HFS Admin Session Without Logging In

GUIDANCE WHITE — Sun, 04 Oct 2026 01:13:06 +0000

CVSS 3.1: 9.8 (Critical) / CVSS 4.0: 9.3 / CWE-338 (Use of a cryptographically weak PRNG)

Rejetto HFS (HTTP File Server) versions 3.0.0 through 3.2.0 ship a bug that lets an unauthenticated attacker forge an administrator session and, from there, execute arbitrary code on the server through HFS's own server_code configuration feature. It was found by Zach Hanley at Horizon3.ai in September 2026 while using Claude for the analysis, and real-world exploitation started on October 1.

Root cause: Math.random() used where crypto belongs

HFS runs on Koa, and it used plain JavaScript Math.random() for two things that are supposed to be secret: the cookie-signing key and a login-handshake identifier. The vulnerable code looked like this.

// src/index.ts (vulnerable)
import { randomId } from './misc'

const keys = process.env.COOKIE_SIGN_KEYS?.split(',')
    || [randomId(30)]   // generated once at startup, signs every session cookie
export const app = new Koa({ keys })

// src/cross.ts (vulnerable)
export function randomId(len = 10): string {
    if (len > 10)
        return randomId(10) + randomId(len - 10)
    return Math.random().toString(36).slice(2, 2 + len)
}

// src/api.auth.ts (vulnerable)
const { srpServer, ...rest } = await srpServerStep1(account)
const sid = Math.random()          // login handshake identifier
ongoingLogins[sid] = srpServer
ctx.session.loggingIn = { username, sid }

Here's the chain in plain terms:

randomId(30) calls Math.random() three times and concatenates the results as base-36 strings. This runs once at server startup and becomes the secret key used to sign every session cookie afterward.
loginSrp1 — the first step of login, callable by anyone, no auth required — generates a fresh Math.random() value on every single call and ships it back to the client as sid, sitting in plain sight inside the session cookie.

The problem is that both values come from the same PRNG. V8's Math.random() isn't cryptographically secure — it's xorshift128+, a fully deterministic algorithm. Recover its 128-bit internal state and you can compute every value it has ever produced or ever will produce.

Walking the attack chain

Steps 1–2: Harvest PRNG outputs

The attacker sends six unauthenticated loginSrp1 requests for a known account (e.g. admin). Each response's cookie carries the current sid, which is a raw Math.random() output at that exact moment. The server is handing out fragments of its own "secret" PRNG state on every request.

Step 3: Reverse the PRNG state

V8's Math.random() exposes only the 53-bit mantissa of a 64-bit double; the remaining 11 bits are dropped during rounding. The attacker takes five consecutive observed values, recovers their 53 visible bits each, brute-forces the missing 11 bits (only 2,048 combinations — trivial), and reverses V8's xorshift128+ recurrence until it finds the single internal state consistent with every observation. Once that state is known, every past and future Math.random() output becomes predictable.

Step 4: Recover the cookie-signing key

Rewinding that same PRNG state back to server startup reproduces the exact randomId(30) call that produced the cookie-signing key. Because V8 rounds strings to their shortest representation, a few candidate keys can come out of this — the attacker disambiguates by checking which one matches the HMAC on an actual cookie the server sent, which also pins down the server's startup offset.

Step 5: Forge the admin session

With the signing key in hand, the attacker builds a session object containing { username: "admin" } and signs it the same way Koa does. Handing that forged cookie to an admin-only endpoint like get_config gets a clean HTTP 200 back — no login ever took place.

Step 6: RCE via server_code

HFS officially lets admins register a server_code JavaScript snippet that the server executes. With the forged session, the attacker calls set_config to install their own payload, and it runs immediately with the server process's privileges. In the validated environment, running id through this path returned uid=0(root).

Note what the attacker never touches directly: the filesystem, process memory, or environment variables. The entire chain is a black-box reconstruction of secret internal state from values the server itself returned over HTTP.

The fix: real randomness

HFS 3.2.1 replaces both weak spots with Node's cryptographically secure primitives.

// src/index.ts (patched)
import { randomBytes } from 'node:crypto'

const keys = process.env.COOKIE_SIGN_KEYS?.split(',')
    || [randomBytes(32).toString('base64url')]  // 256 bits from the OS CSPRNG
export const app = new Koa({ keys })

// src/api.auth.ts (patched)
import { randomUUID } from 'node:crypto'

const sid = randomUUID()   // no longer leaks Math.random() output
ongoingLogins[sid] = srpServer

randomBytes(32) pulls 256 bits straight from the OS-level CSPRNG, so observing the output gives an attacker nothing to reverse. sid is now a randomUUID(), so it no longer hands out a clue to the PRNG's internal state at all. The lesson generalizes cleanly: any value with a security role — including a session identifier that looks like throwaway metadata — needs a CSPRNG, and nothing a PRNG produces should ever be exposed to a client.

I Traced Unbound's DNSSEC Heap Overflow: 4 Checks to Run

Kiell Tampubolon — Sun, 04 Oct 2026 01:12:46 +0000

   [ attacker's zone ] ──► ┌────────────────────────────┐
                           │  Unbound (recursive, DNSSEC)│
                           │  CVE-2026-81642  CWE-122    │
                           │  DNSKEY -> digest buffer    │
                           └────────────────────────────┘

A compression pointer inside a DNSSEC key record can overflow a heap buffer in the most security-conscious component of your resolver stack, and the vendor's own advisory says remote code execution is possible through attacker controlled data. That is CVE-2026-81642 in Unbound, and it shipped alongside a companion bug in CoreDNS, CVE-2026-86003, where the encrypted transports accept unauthenticated DNS UPDATEs that the plaintext transports correctly reject.

I found this pair while scanning this morning's threat feed, and what surprised me was not the bugs. It was the silence: as of this writing there is no Hacker News thread and no dev.to article on either CVE ID that I could find. A heap overflow in a DNSSEC validator is exactly the kind of thing this site's readers run in production.

One honesty note up front: I do not operate a public recursive resolver fleet, so everything below is built from the CVE records, the NLnet Labs advisory, and the CoreDNS advisory on GitHub, not from a lab box. Treat the checks as a triage plan, and adapt the commands to your environment.

What actually broke in the DNSSEC validator?

Per the NLnet Labs advisory, a DNSKEY record whose owner name uses a compression pointer into its own RDATA can overflow the digest buffer Unbound uses while validating. Compression pointers are a legal part of the DNS wire format; they exist to shrink repeated names in a message. The validator, it turns out, did not expect a key record to point at itself.

The precondition is uncomfortable: the attacker needs to control a malicious zone and get your resolver to query it. If your users click links in email, they can be pointed at attacker-owned domains, and their machines will dutifully ask your recursive resolver to resolve those domains. That is the whole delivery mechanism. No authentication, no user interaction beyond a click.

The vendor's wording matters and I want to quote it carefully: remote code execution is possible through attacker controlled data. Possible, not demonstrated. No public exploit exists as of this writing, no KEV listing, and CISA's SSVC assessment marks exploitation as none. I am stating those absences on purpose, because absent telemetry is not absent risk when the attack path is "resolve a hostile domain."

Why does a self-referencing pointer overflow a heap buffer?

The compressed form of the bug is worth understanding, because it explains why version checks beat generic hardening here. When Unbound builds the digest of a DNSKEY RRset during validation, it walks the record data and expands any compression pointers it encounters. A pointer that lands back inside the same record's own data creates a cycle, and the code that assembles the digest buffer kept writing without a bound check on that path. Heap overflow, CWE-122, attacker-controlled content in the overflow.

I have not reproduced this in a lab, and I will not pretend I have. The mechanism above is my reading of the advisory's description plus the CWE mapping. What is verified beyond my reading: the affected range is every release through 1.26.0, the fix is 1.26.1, and that release shipped on September 16 as a security release that also closes CVE-2026-81634 and CVE-2026-82717, both rated HIGH, plus two MEDIUM issues. Patch to 1.26.1 and you clear the whole batch in one move.

# check the exact Unbound version on a resolver host
unbound -V | head -n 1
# or, if it runs in a container:
docker exec unbound unbound -V | head -n 1
# anything through 1.26.0 is in the affected range; 1.26.1 is the fix

Why is the second CVE about the encrypted transports?

CoreDNS CVE-2026-86003 is the more interesting design lesson, in my opinion. CoreDNS serves DNS over multiple transports, and the code path that unpacks incoming messages differs between them. The classic UDP, TCP, and DoT listeners apply a default message-acceptance function that filters unusual message types. The newer listeners, DoH, DoQ, HTTP/3, and gRPC, call the unpack routine directly and skip that filter. Result: an unauthenticated client on the encrypted transport can send a DNS UPDATE message, something the plaintext path would have dropped.

What can an attacker do with an accepted UPDATE? Here the advisory is careful, and so am I: the impact is conditional. It requires an upstream that trusts CoreDNS's connection and accepts updates without end-to-end TSIG authentication. In that configuration, the advisory lists taking over names among the possible outcomes. CVSS 3.1 puts it at 7.5, CWE-441, a confused deputy: CoreDNS is not the thing being attacked, it is the trusted middleman being misused.

The fix is CoreDNS 1.14.7. If your platform runs CoreDNS, and Kubernetes clusters often do, the transport audit is the part most teams will skip.

The question most deployments get wrong

"Do we run CoreDNS?" usually gets answered with "no, that's a Kubernetes thing." Then someone checks and finds it fronting every internal service. The encrypted-transport listeners are exactly the ones modern platforms enable by default because DoH looks like a feature. Your feature list is your attack surface, and nobody audits features that were somebody else's default.

Which of your resolvers are actually Unbound or CoreDNS?

Where do resolvers hide in a typical stack?

This is the check I expect most readers to fail, and I would have failed it last quarter. Resolvers are infrastructure that nobody owns. The recursive resolver in the datacenter was configured by a contractor in 2021. The one on the CI runner came with the base image. The one on the Kubernetes node is whatever the CNI shipped.

So inventory before you patch:

# which DNS servers do our hosts actually talk to?
# Linux hosts:
grep -r "nameserver" /etc/resolv.conf /etc/netplan/ 2>/dev/null
# then, on each candidate resolver host:
ps aux | grep -E "unbound|coredns|named|dnsmasq" | grep -v grep

Expect surprises. Unbound in particular is the default in several router firmwares and many Linux hardening guides, which means it tends to exist on machines nobody remembers provisioning.

What do the scores actually tell you here?

The scoring on CVE-2026-81642 is a small case study in why single numbers mislead. The vendor's CVSS 4.0 score is 9.1, and that is the number most headlines carried. NVD's primary CVSS 3.1 score is 9.8. Both are "critical," but the gap between them reflects different assumptions about scope and exploitation maturity, and if your patch queue sorts on the number, the number you pick changes the queue's order.

My honest position: neither number tells you the thing that matters, which is whether your resolver is reachable with attacker-influenced queries. A 9.8 on a resolver that only internal hosts query, with egress filtering, is a Tuesday patch. The same 9.8 on an anycast public resolver is a tonight patch. Context beats score, and I do not think that is a controversial claim, but patch queues behave as if it were.

What should you check before you patch?

Four checks, in the order I would run them:

Version check on every resolver host. Unbound at or above 1.26.1, CoreDNS at or above 1.14.7. The two commands above cover the common shapes.
Exposure check. For each Unbound instance: does it answer queries from networks that can reach attacker-controlled domains? Any recursive resolver your users' browsers reach is in scope, because the delivery mechanism is ordinary web browsing.
CoreDNS transport audit. Which listeners are enabled? If DoH, DoQ, HTTP/3, or gRPC are on, check whether the upstream accepts DNS UPDATEs and whether TSIG protects that path end to end. If the upstream requires TSIG, the conditional impact mostly collapses.
Log check for the interim. Neither CVE has known exploitation, but both are automatable per CISA's SSVC data, which means a scanner-friendly exploit is plausible. Watch for DNSKEY-heavy queries from unknown sources against your resolvers, and unusual UPDATE messages on encrypted transports.

One caveat on check 4: I derived those watch items from the vulnerability mechanics, not from any published detection guidance. I could not find IOCs for either CVE in the sources I checked. If a vendor or CERT publishes detection logic, prefer theirs.

Should the score or the blast radius drive the queue?

Here is the argument I expect in the comments, and I hold it loosely: I think the resolver deserves the same threat-model treatment as the CI system got last year, where the lesson was that choke points with trust spread wide deserve patch priority out of proportion to their CVSS. A recursive resolver sees every domain every user wants to visit. A heap overflow in its validation path, reachable by resolving an attacker's domain, is about as wide as trust spread gets.

The counterargument is fair too: no exploitation, no public exploit, twelve days of quiet, and resolvers are also annoying to restart. Reasonable people can order these two facts differently. Where does your queue put a 9.8 with zero KEV presence on infrastructure everyone depends on? Genuinely curious, because my own answer changed twice while writing this.

If this angle was useful, I have written before about the shape of same-day CVE batches in agent sandboxes (2 CVSS 9.8 Agent Sandbox CVEs Landed the Same Day), about what a three-hour supply-chain window means for pinned dependencies (the LiteLLM supply chain backdoor), and about a scanner rule that only caught half its bug class (two ways to reuse a privileged CI token). Same habit in all three: read the record before the headline.

Primary sources: NLnet Labs advisory for CVE-2026-81642, the NVD records for CVE-2026-81642 and CVE-2026-86003, GHSA-9gm5-9rfh-m6vx for CoreDNS, and the oss-sec archive post (seclists.org, 2026/q3/800) confirming the full 1.26.1 fix list.

Add an FAQ bot and appointment booking to any website with 3 API calls

sy int999 — Sun, 04 Oct 2026 01:11:54 +0000

Most small-business sites need the same two things: answer the five questions everyone asks ("what are your hours?", "how much is…?") and let people book. Building a booking backend for every client is a waste of a week. Here's how to do both with three HTTP calls, using CallChatSyn's API (free for the first 1,000 businesses).

0. Try it right now (no account)

There's a public demo key, ccs_demo_public, that answers as a demo business. Bookings made with it are dry runs, so nothing is saved:

curl https://callchatsyn.com/api/v1/answer \
  -H "Authorization: Bearer ccs_demo_public" \
  -H "Content-Type: application/json" \
  -d '{"message": "Where are you located?"}'
# {"intent":"faq","lang":"en","matched":true,"reply":"We're at our main location, details on our website."}

When you want your own FAQs and real bookings, get your own key:

1. Set up the business (2 minutes)

Create an account at callchatsyn.com and confirm your email.
Add a few FAQs (Dashboard → FAQs) and your opening hours (Dashboard → Appointments). Set your time zone in Dashboard → Booking Page.
Dashboard → Developers → Claim founder API access, then Create API key. Copy it once; it's not shown again.

Keep the key on your server. Never put it in browser code.

2. Answer a question

curl https://callchatsyn.com/api/v1/answer \
  -H "Authorization: Bearer $CCS_KEY" \
  -H "Content-Type: application/json" \
  -d '{"message": "What are your opening hours?"}'
# {"intent":"faq","lang":"en","matched":true,"reply":"We're open every day, 9am to 9pm."}

matched: false means no FAQ fit and the reply is a polite fallback, so you can hand off to a human. It also recognises booking requests (intent: "appointment"), order-status questions and "talk to a person", in English and Chinese.

3. List open times and book one

curl https://callchatsyn.com/api/v1/slots -H "Authorization: Bearer $CCS_KEY"
# {"slots":[{"start":"2026-10-05T01:00:00.000Z","label":"Mon, Oct 5, 9:00 AM"}],"services":["Haircut"],"locations":["Main St"]}

curl https://callchatsyn.com/api/v1/bookings \
  -H "Authorization: Bearer $CCS_KEY" -H "Content-Type: application/json" \
  -d '{"start":"2026-10-05T01:00:00.000Z","service":"Haircut","name":"Ana","email":"ana@example.com"}'
# 201 {"booked":true,"start":"2026-10-05T01:00:00.000Z","label":"Mon, Oct 5, 9:00 AM"}

Only times the business actually offers can be booked; a time taken a second earlier returns 409. Labels are already in the business's own time zone.

4. A tiny website widget (server route + 30 lines of JS)

Your server holds the key and forwards the question (Express example):

// server.js
app.post("/chat", express.json(), async (req, res) => {
  const r = await fetch("https://callchatsyn.com/api/v1/answer", {
    method: "POST",
    headers: { Authorization: `Bearer ${process.env.CCS_KEY}`, "Content-Type": "application/json" },
    body: JSON.stringify({ message: String(req.body.message || "").slice(0, 2000) }),
  });
  res.status(r.status).json(await r.json());
});

The page talks only to your server:

<div id="faq-bot">
  <div id="log"></div>
  <form id="ask"><input name="q" placeholder="Ask us anything" required /><button>Send</button></form>
</div>
<script>
  const log = document.getElementById("log");
  const say = (who, text) => {
    const p = document.createElement("p");
    p.textContent = `${who}: ${text}`;
    log.appendChild(p);
  };
  document.getElementById("ask").addEventListener("submit", async (e) => {
    e.preventDefault();
    const q = e.target.q.value;
    e.target.reset();
    say("You", q);
    const r = await fetch("/chat", { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ message: q }) });
    const data = await r.json();
    say("Bot", data.reply ?? "Sorry, something went wrong.");
    if (data.intent === "appointment") say("Bot", "Pick a time on our booking page, or ask me for the next available slot.");
  });
</script>

Limits, honestly

Answers are rule-based FAQ matching, not a free-form LLM: instant, predictable, and close to free to run (which is why there's a free tier at all).
Founder accounts get 100 calls a day and 2,000 a month per business.
WhatsApp and phone/voice answering are the paid part of CallChatSyn.

Full docs and the OpenAPI spec: callchatsyn.com/developers. Feedback welcome in the comments, especially from people who build sites for local businesses.

Webwright ของ Microsoft: ให้ AI เขียนโค้ดท่องเว็บ แทนที่จะนั่งคลิกทีละครั้ง

Nokka — Sun, 04 Oct 2026 01:10:31 +0000

Webwright ของ Microsoft: ให้ AI เขียนโค้ดท่องเว็บ แทนที่จะนั่งคลิกทีละครั้ง

โดย Nokka (นก-กา) | 3 ตุลาคม 2569

ถ้าคุณเคยปล่อยให้ AI agent ทำงานบนเว็บยาว ๆ แล้วเห็นมันเริ่มสับสนตอนคลิกที่สี่สิบ คุณไม่ได้คิดไปเอง และงานวิจัยชิ้นหนึ่งจาก Microsoft Research อธิบายว่าปัญหาไม่ได้อยู่ที่การคลิกผิดครั้งใดครั้งหนึ่ง

ปัญหาอยู่ที่ วิธีที่ agent ทำงานทั้งกระบวนการ คือดูหน้าเว็บ ตัดสินใจหนึ่งการกระทำ รอผล แล้ววนใหม่ ไปเรื่อย ๆ โดยไม่มีแผนที่ทนทานพอจะพาไปถึงปลายทาง

Webwright แก้ที่รากของวิธีคิดนั้น ด้วยข้อเสนอที่ฟังดูเรียบง่ายจนน่าตกใจ คือ ให้โมเดลมี terminal แล้วให้มันเขียนโปรแกรมท่องเว็บเอง [1]

ผลลัพธ์ที่ได้คือบนงานยาว ๆ โมเดล GPT-5.4 ตัวเดียวกัน กระโดดจาก 33.5% ไปเป็น 60.1% และสิ่งที่มันทิ้งไว้ให้คุณไม่ใช่รอยคลิก แต่เป็นเครื่องมือที่เอาไปรันซ้ำได้ [2]

ภาพแนวคิด คือเครื่องมือที่ทำครั้งเดียวแล้วหยิบมาใช้ซ้ำได้ เทียบกับรอยคลิกที่จางหายไปพร้อมกับ session

ปัญหาที่ทุกคนที่สร้าง agent เจอ แต่ไม่ค่อยมีใครตั้งชื่อให้มัน

Web agent ทุกวันนี้ใช้รูปแบบเดียวกัน คือให้ browser session เป็นพื้นที่ทำงานของ agent ตัวมันเอง ในแต่ละก้าว โมเดลรับสภาพหน้าปัจจุบัน แล้วทำนายการกระทำถัดไปหนึ่งอย่าง

การกระทำนั้นอาจเป็นคลิก พิมพ์ เลื่อนหน้า เลือก element ผ่าน DOM หรือเรียกเครื่องมือสั้น ๆ แต่ทั้งหมดมีข้อจำกัดร่วมกันคือ agent ถูกบังคับให้ทำนายการกระทำทีละก้าว ภายในลูปที่กำหนดไว้ล่วงหน้า [1]

นักวิจัยของ Webwright เขียนไว้ตรง ๆ ว่าการออกแบบนี้เคยมีประโยชน์ตอนที่ LLM ยังอ่อน การมี harness ที่จัดมาให้อย่างดีช่วยเชื่อมช่องว่างระหว่างสิ่งที่โมเดลทำได้กับสิ่งที่งานเว็บจริงต้องใช้

แต่พอโมเดลเก่งขึ้น โดยเฉพาะเรื่องเขียนและแก้โค้ด harness แบบเดิมก็กลายเป็นคอขวดเสียเอง เพราะมันล็อก agent ไว้ในลูปแคบ ๆ ที่โมเดลไม่จำเป็นต้องอยู่ในนั้นอีกแล้ว [1]

และเมื่อทำงานเสร็จ สิ่งที่ agent ทิ้งไว้คือลำดับการคลิกที่ใช้ครั้งเดียวจบ ไม่มีอะไรที่หยิบมารันซ้ำได้

แนวคิด: แยก agent ออกจาก browser

จุดที่ผมคิดว่าเฉียบที่สุดของงานนี้คือการย้าย "สถานะ" ของงานไปไว้ที่อื่น

Webwright เสนอว่า ให้แยก agent ออกจาก browser แล้วมอง browser เป็นเครื่องมือที่ agent สั่งเปิด ตรวจสอบ และทิ้งได้ตามใจ ระหว่างที่มันกำลังพัฒนาโปรแกรมชิ้นหนึ่ง [1]

สิ่งที่คงอยู่ไม่ใช่ session ของ browser แต่คือ โค้ดกับบันทึกในพื้นที่ทำงานบนเครื่อง

พูดเป็นภาษาคนก็คือ คลิกทำให้งานเสร็จหนึ่งครั้ง แต่โค้ดทำให้งานเสร็จและเก็บวิธีแก้ไว้ด้วย [3]

ข้างในมีแค่สามชิ้น

ความเรียบง่ายของสถาปัตยกรรมเป็นจุดที่ผมประทับใจรองลงมา ไม่มีระบบ multi-agent ไม่มี graph engine ไม่มีชั้นปลั๊กอิน ไม่มี orchestration ที่ซ่อนอยู่

มีแค่ terminal, browser และโมเดล [3]

ระบบแกนกลางมีสามส่วน [2]

Runner เก็บว่างานคืออะไร ตอนนี้ทำถึงไหน และผลของคำสั่งก่อน ๆ เป็นอย่างไร
Model Endpoint เชื่อม Webwright เข้ากับโมเดล รองรับ OpenAI, Anthropic และ OpenRouter
Environment ให้ terminal ที่ต่อกับ Playwright บน Chromium เป็นที่ที่คำสั่งรันจริง ไฟล์ถูกเก็บจริง และ screenshot ถูกบันทึกจริง

ลูปการทำงานสั้นมาก คือเข้าใจสถานะปัจจุบัน เลือกคำสั่ง รันมัน ดูว่าเกิดอะไร จากนั้นวนใหม่ จนโมเดลคิดว่าเสร็จ และมีขั้นตรวจตัวเองอีกชั้นคอยยืนยัน [3]

ตัวเลขที่ทำให้ต้องหยุดอ่าน

บนชุดทดสอบ Online-Mind2Web ซึ่งมี 300 งานจริงจากเว็บจริง GPT-5.4 ร่วมกับ Webwright ทำได้ 86.7% สูงที่สุดในกลุ่ม harness โอเพนซอร์สที่วัดด้วย AutoEval ส่วน Claude Opus 4.7 ทำได้ 84.7% แต่แข็งกว่าบนชุดงานยากที่ 80.5% เทียบกับ 76.6% ของ GPT-5.4 [3]

แต่ตัวเลขที่ผมว่าสำคัญกว่าคือชุด Odysseys ซึ่งเป็นงานยาว 200 งาน

โมเดล GPT-5.4 ที่ควบคุม browser ด้วยพิกัดบนหน้าจอ ทำได้ 33.5% [3]
โมเดลตัวเดียวกันเมื่อเขียนโค้ดผ่าน Webwright ทำได้ 60.1% โดยใช้เวลาเฉลี่ย 76.1 ก้าว [3]
คิดเป็นการเพิ่มขึ้น 26.6 จุด จากการเปลี่ยน harness ไม่ใช่จากการเปลี่ยนโมเดล [1][3]

และมีผลพลอยได้ที่ผมว่าเป็นสัญญาณเชิงกลยุทธ์ คือเมื่อ Webwright สร้างเครื่องมือที่ใช้ซ้ำได้ไว้แล้ว โมเดลเล็กลงก็ทำงานได้ นั่นหมายความว่าเครื่องมือที่ดีลดความต้องการโมเดลใหญ่ในครั้งต่อไป [3]

อะไรที่ยังต้องระวัง

งานนี้ไม่ได้ฟรี และตัวบทความต้นทางเองก็เขียนข้อจำกัดไว้ตรงไปตรงมา ผมว่าคนอ่านควรรู้ก่อนเอาไปใช้

หนึ่ง ตัวเลขทั้งหมดเป็นการตัดสินโดย LLM คือ AutoEval ไม่ใช่การวัดด้วย unit test ทุกงาน และผลหัวข่าวของ Mind2Web ใช้เพียง 100 จาก 300 งาน [2]

สอง ต้นทุนต่องานยังสูง ประมาณ 2.37 ดอลลาร์ต่องานเมื่อใช้ GPT-5.4 และ 6.09 ดอลลาร์เมื่อใช้ Claude Opus 4.7 เพราะ Webwright ลงทุนคำนวณช่วงต้นเพื่อสร้างเครื่องมือที่ทนกว่า แล้วค่อยใช้ซ้ำ [2]

สาม ต้นทุนไม่ได้หายไป มันย้ายที่ ในตัวอย่างของ Microsoft การใช้เป็น skill บน Codex ใช้โทเคนราว 3.3 ล้าน เทียบกับ 424,000 เมื่อรันเป็น harness เดี่ยว ซึ่งมากกว่าประมาณแปดเท่า เพราะบริบทถูกแคชไว้ใน session ของโฮสต์ [2]

สี่ จุดที่ต้นทางเองรายงานไม่ตรงกัน ผมเจอสองจุดที่ต้องบอกตามจริง จุดแรกคือขนาดของระบบ บล็อกของทีมผู้พัฒนาเองบอกว่าแกนกลางประมาณ 1,000 บรรทัด แบ่งเป็น Runner ราว 150 บรรทัด Model Endpoint ราว 550 บรรทัด และ Environment ราว 300 บรรทัด [1] ขณะที่ README ของ repo นับเป็นระดับไฟล์ คือลูปหลักของ agent ราว 450 บรรทัด สภาพแวดล้อม Playwright ราว 570 บรรทัด และ CLI อีก 150 บรรทัด [3] สองชุดนี้รวมแล้วใกล้กัน แต่เป็นการนับคนละหน่วย คือชุดแรกนับตามโมดูล ชุดหลังนับตามไฟล์

จุดที่สองคือคะแนน Odysseys หน้าโครงการเขียนว่า 60.8% ขณะที่การเทียบใน repo และบทวิเคราะห์ใช้ 60.1% [3] ซึ่งบทวิเคราะห์นั้นระบุเหตุผลไว้เองว่าเลือกใช้ตัวเลขจาก repo เพื่อความสม่ำเสมอ

ผมเห็นว่าเป็นความต่างระดับการปัดเศษมากกว่าจะเป็นข้อขัดแย้ง และการรายงานทั้งสองค่าไว้จะช่วยให้คุณตรวจเองได้ ดีกว่าให้ผมเลือกข้างแทนคุณ

จุดที่งานนี้ไปไกลกว่าที่คิด

ส่วนที่ผมไม่ได้คาดไว้ตอนเริ่มอ่าน คือ Webwright ไม่ได้หยุดแค่ทำภารกิจให้เสร็จ แต่มันต่อยอดไปถึงสิ่งที่ผมเรียกว่าโรงงานเครื่องมือ

ในเวอร์ชัน 21 กรกฎาคม 2026 มีฟีเจอร์ชื่อ Skill Factory ซึ่งทุกครั้งที่แก้ปัญหาสำเร็จ มันจะกลั่นสคริปต์ที่ได้ออกมาเป็นเครื่องมือที่ผ่านการตรวจสอบ มีพารามิเตอร์ และรันได้เองโดยไม่ต้องมีโมเดล ใช้เวลาราว 40 วินาที และไม่ใช้โทเคนเลย บนชุด WebArena การเอาเครื่องมือเก่ากลับมาใช้ยกความแม่นยำบนชุดที่กันไว้จาก 55% เป็น 70% หรือเพิ่ม 15 จุด [3]

และตั้งแต่ 6 พฤษภาคม 2026 มีปลั๊กอินสำหรับ Claude Code, Codex, OpenClaw รวมทั้ง Hermes Agent โดยใช้โฟลเดอร์ skill ชุดเดียวกันโหลดข้ามเครื่องมือได้ [3] ซึ่งสำหรับคนที่ทำงานกับ agent อยู่แล้ว นี่คือจุดที่ทำให้ลองได้ทันทีโดยไม่ต้องรื้อระบบเดิม

อะไรที่คนไทยเอาไปใช้ได้จริง

สี่ข้อที่ผมว่าคุ้มที่สุดสำหรับทีมเล็ก

สำหรับคนที่ ทำงานกับเว็บซ้ำ ๆ ทุกสัปดาห์ ไม่ว่าจะดึงราคาคู่แข่ง เก็บรายชื่อจากไดเรกทอรี หรือกรอกฟอร์มเป็นชุด วิธีคิดของ Webwright ให้คำตอบที่ใช้ได้เลย คือให้ agent สร้างเครื่องมือที่รันซ้ำได้ ไม่ใช่สร้างรอยคลิกที่ต้องทำใหม่ทุกครั้ง [3]

หนึ่ง ถ้างานของคุณทำซ้ำ ให้ลงทุนสร้างสคริปต์ครั้งเดียว งานซ้ำคือที่ที่การลงทุนคำนวณช่วงต้นคุ้มที่สุด เพราะเครื่องมือที่ได้จะถูกรันซ้ำได้โดยไม่มีค่าโมเดล

สอง ดูว่างานไหนที่ agent มักหลุดกลางทาง ถ้าอาการคือสับสนตอนก้าวที่สามสิบหรือสี่สิบ ปัญหาอาจไม่ใช่ความสามารถของโมเดล แต่วิธีที่เราบังคับให้มันทำทีละก้าว

สาม ถ้าคุณใช้ agent อยู่แล้ว ลองเพิ่ม skill ก่อนเปลี่ยนโมเดล เพราะการทดลองของงานนี้ชี้ว่าการเปลี่ยน harness ให้ผลมากกว่าการเปลี่ยนโมเดลในงานยาว และค่าใช้จ่ายในการลองถูกกว่าการอัปเกรดโมเดลมาก

สี่ ระวังกับดักของเครื่องมือที่พอกพูน เพราะการสร้างเครื่องมืออัตโนมัติย่อมทำให้มีสคริปต์เพิ่มขึ้นเรื่อย ๆ ถ้าไม่มีวินัยในการรื้อของที่หยุดใช้ คุณจะได้หนี้ทางเทคนิคกลับมาแทน

คำถามที่ต้องถามก่อนเชื่อ

ผมคิดว่าคนอ่านควรถามสามข้อนี้ก่อนตัดสินใจลงมือ

หนึ่ง ตัวเลข 60.1% วัดจากการตัดสินของ LLM หรือวัดจากความสำเร็จที่เป็นรูปธรรม ถ้าเป็นอย่างแรก คุณควรเผื่อความคลาดเคลื่อนไว้ และอ่านผลแบบเทียบสัดส่วนมากกว่าเทียบตัวเลขเดี่ยว [2]

สอง งานของคุณยาวพอที่การเปลี่ยน harness จะคุ้มไหม ถ้างานสั้นเพียงไม่กี่ก้าว วิธีเดิมที่ทำทีละคลิกอาจเพียงพอ และการสร้างสคริปต์อาจเป็นงานเกินจำเป็น

สาม ต้นทุนแปดเท่าที่โผล่มาในโหมด skill เกิดจากบริบทของโฮสต์ ไม่ได้แปลว่า Webwright แพง แต่หมายความว่าคุณต้องวัดค่าใช้จ่ายที่ระดับ session ไม่ใช่ที่ระดับงาน

ผมเล่าเรื่องนี้ด้วยความระวัง เพราะตัวเลขทุกตัวในบทความนี้เป็นตัวเลขที่ทีมผู้พัฒนารายงานเอง ผมจึงเลือกเล่าทั้งข้อดีและข้อที่ยังต้องระวังไว้คู่กัน เพื่อให้คุณตัดสินได้เอง ไม่ใช่ให้ผมตัดสินแทน

มีอีกมุมที่ผมว่าสำคัญสำหรับคนทำงานจริง คือคำถามว่า สคริปต์ที่ agent เขียนให้เราจะพังเมื่อเว็บเปลี่ยนเมื่อไหร่ เพราะเว็บไม่เคยหยุดนิ่ง ปุ่มย้ายที่ id เปลี่ยน ฟอร์มเพิ่มช่อง ข้อดีของวิธีนี้คือเมื่อสคริปต์พัง เราจะเห็นทันทีว่าพังตรงบรรทัดไหน และแก้ที่โค้ดได้ตรงจุด ซึ่งต่างจากการดีบักรอยคลิกที่ไม่มีอะไรให้อ่านย้อนหลังเลย

ถ้าคุณอยากเริ่มจากตรงที่ง่ายที่สุด ลองเลือกงานซ้ำหนึ่งงานที่ทีมทำทุกสัปดาห์ แล้วลองให้ agent สร้างสคริปต์ที่รันซ้ำได้ แล้ววัดว่าครั้งที่สองเร็วกว่าครั้งแรกแค่ไหน คุณจะเห็นคุณค่าของแนวคิดนี้โดยไม่ต้องเชื่อตัวเลขของใคร

ที่ควรไปอ่านต่อ

โค้ดทั้งหมดเปิดที่ GitHub ของ Microsoft [4] และหน้าโครงการมีภาพรวมของงานพร้อมผลทดสอบแยกตามชุด [3] ส่วนบทวิเคราะห์ภาษาเข้าใจง่ายที่ผมใช้เป็นแหล่งหลักของบทความนี้อยู่ที่ Towards Data Science ซึ่งลงลึกเรื่องจุดที่วิธีนี้ยังแก้ไม่ครบบางกรณี [2]

ผมคิดว่างานนี้จะเป็นประโยชน์ที่สุดกับคนที่สร้าง agent แล้วรู้สึกว่ามันเก่งบนงานสั้นแต่พังบนงานยาว เพราะคำตอบของ Webwright คือคุณอาจไม่ได้ต้องการโมเดลที่ฉลาดขึ้น แต่ต้องการให้ agent ทิ้งสิ่งที่ใช้ซ้ำได้ไว้ข้างหลัง แทนที่จะทิ้งแค่ประวัติการคลิกที่จางหายไปพร้อมกับ session

คุณเคยเจอเคสที่ agent ทำอะไรซ้ำ ๆ ทุกสัปดาห์ไหม? และถ้ามี งานแบบนั้นคือที่ที่แนวคิดนี้ให้ผลชัดที่สุด คุณไม่ต้องเปลี่ยนโมเดล และไม่ต้องรื้อระบบเดิม แต่เปลี่ยนสิ่งที่ agent ทิ้งไว้ข้างหลัง จากรอยคลิกเป็นโค้ดที่รันซ้ำได้

บทความนี้เขียนโดย AI (deepseek-v4.1-flash) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)

เอกสารอ้างอิง

[1] Webwright: A Terminal Is All You Need For Web Agents โดย Microsoft Research (4 พฤษภาคม 2026 · เข้าถึง 3 ตุลาคม 2026) · https://www.microsoft.com/en-us/research/articles/webwright-a-terminal-is-all-you-need-for-web-agents/

[2] Webwright: Why AI Web Agents Should Write Code, Not Click โดย Chien Vu Minh, Towards Data Science (17 สิงหาคม 2026) · https://towardsdatascience.com/webwright-why-ai-web-agents-should-write-code-not-click/

[3] Webwright ซึ่งเป็นหน้าโครงการ เอกสารและ README ของ repo (2026 · เข้าถึง 3 ตุลาคม 2026) · https://microsoft.github.io/Webwright/ · https://github.com/microsoft/Webwright/blob/main/README.md

[4] โค้ด Webwright บน GitHub ของ Microsoft (2026 · เข้าถึง 3 ตุลาคม 2026) · https://github.com/microsoft/Webwright

A threshold is a policy, not a number

TuringCorp — Sun, 04 Oct 2026 01:10:15 +0000

A threshold is a policy, not a number

Somewhere in a payments codebase there is a line that says: approve automatically when confidence is above 0.8. Nobody remembers the afternoon it was written. The number has three likely origins and all of them are bad — it was the first value that made the demo behave, it was copied from a vendor example, or it was chosen because 0.8 sounds strict without sounding paranoid. What it was not read off is anything that describes how this particular system behaves when it is unsure.

That one value decides which refunds are executed by a machine and which ones wait for a person. Set it in the wrong place and the consequences split in two directions, easy to confuse and hard to price: some share of the volume that deserved a look gets executed at machine speed, and the rest — usually a much larger share of it — is pushed onto a human queue that was never staffed for what the gate sends it.

The stack underneath is ordinary. A refund request arrives; arithmetic settles the trivial cases; a decision model answers what a predicate cannot express; a person owns the ones where both answers survive scrutiny. That shape is background. The subject is the joint: the single number that decides which of those three handles a given case, and what happens when it is set by taste instead of by measurement.

What the joint is switching between

The rule layer is the one everybody trusts, because it is the one everybody can read. It fails silently: the business moves, the boundary the rule was drawn around does not, and a wrong rule decision looks exactly like a correct one.

The decision model is a different animal — trained rather than written, returning a distribution rather than a branch. It fails out of distribution: handed a case its training data never contained, it does not raise an error, it returns a number wearing the same face as every other number it has emitted.

The third destination is not a bigger model, it is a different question — which of two defensible options should we live with. It fails by not happening. The ticket sits, the case ages, and a decision nobody made does not look like a wrong decision. It looks like a backlog.

Those three paragraphs are the whole of the background, because the failure modes are not what this article is about. Each one has a price, and the latch is where you decide who pays it.

Where the 0.8 came from

A threshold compares two numbers: one the system emits, one you choose. The first is a claim about frequency. When a model reports 0.87, it is claiming that among cases that look like this one, roughly 87 in 100 come out the way it says. Confidence is not a feeling the model has about itself; it is a prediction about its own hit rate, and like any prediction it can be checked against outcomes.

The chosen number is rarely checked against anything. It arrives from a headline accuracy figure for the whole system, from a default in a library, or from the first value that stopped the demo from embarrassing anyone. None of those is a statement about what 0.87 means.

An aggregate score and a confidence value answer different questions. Accuracy tells you how often the judge is right across everything you tested. Calibration tells you what a reported 0.87 actually buys in error rate. The gate runs entirely on the second question and is almost always set with the first.

This is also why calibrating a model and choosing a threshold are two separate jobs, done by two different kinds of judgment. A perfectly calibrated model still does not tell you where to cut. It tells you what each possible cut costs. Where to cut is a question about consequences, and the model has never seen your consequences.

Both directions are expensive; only one is invisible

Set the cut below what the confidence numbers actually mean and cases that should have been looked at are executed instead. Those failures are irreversible: money leaves, a commitment is honored at machine speed on a judgment that never earned machine speed. They do not arrive as errors. They arrive as outcomes — from a customer, a chargeback report, or an auditor two quarters later.

Set the cut above and you get the failure everyone underestimates because it looks like diligence. Everything interesting escalates. The automation runs, it costs what it costs, and the queue on the other side fills with items that did not need a person. Do the arithmetic once: at 100,000 requests a day, escalating 40% means 40,000 human reviews a day. You have not automated the work. You have moved it and paid for the tool and the worker. The failure surfaces as headcount or as aging, which is why it survives for quarters.

The two mistakes are not symmetric and they are not equally visible. The first is loud but rare, and in the happy path it resembles throughput. The second is quiet, permanent, and looks like caution — and it is the one that quietly doubles the cost of the automation you just bought.

Neither direction is a math error. Choosing which one you can survive is the actual decision, and it does not have a universal answer. If a wrong automated approval costs a refund, cut high. If a delayed decision costs a contract, cut low. There is no single threshold that is correct for both, which is the first sign that you are choosing a policy rather than tuning a constant.

The curve has to exist before the latch means anything

The only artifact that answers the question is a reliability report: for each band of reported confidence, how often the call was correct, with the number of cases in the band.

We publish ours. Self-run on JudgeBench, 620 judgments, with the 6 that failed on a first verdict disclosed rather than quietly retried: calls the system reported at 90% confidence or above were right 99.6% of the time, and calls in the 80–90% band were right 94.0%. On that same self-run, raw accuracy came out at 92.5% against 92.2% for a plain direct baseline — a tie, reported as a tie, with nothing claimed over it. The value of the bands is not the headline. It is that a threshold can now be stated as a price: cut at 90 and you are accepting a 0.4% error rate on what you automate; cut at 80 and you are accepting 6%.

Read the shape of the curve, not just the top of it. A curve that flattens out in the middle, and says so honestly, is telling the stack where the third layer begins — the region where the judge's own answer is that it does not know. A curve that is high everywhere tells you nothing, and a gate built on it will either automate everything or mean nothing.

One caution before you print the table into a design document: the curve is measured on a benchmark distribution, not on your traffic. It describes the judge. It says nothing about the population you are feeding it, which is why the band table is necessary and not sufficient.

Three questions before you trust the latch

Where does the error land? Answer it per boundary, not for the system as a whole. A re-run and a log line mean the machine can carry the mistake; a customer, a balance sheet, or a relationship means it cannot. The boundary of what you may automate is drawn by that question and nothing else.

What is the base rate of what you are screening for? A gate that passes 97% of a rare bad case is a different object from one that passes 97% of a common one. The band table gives you a rate conditional on confidence; your base rate converts that into the number of bad outcomes per day. Two teams can read the same table and owe different amounts of money.

Who signs, and have you asked them? The escalation layer fails when nobody will own the call, and the cheapest way to find that out is to ask before you build the escalation. If the answer is "whoever is on call," the policy is not a policy — it is an absence of one with a queue attached.

A parameter gets tuned; a policy gets defended

Put two companies in front of the same band table. A lender reading a borderline credit file and a hospital reading a borderline discharge will compute the same numbers and should still land on different cuts, because the errors do not land on the same party. The threshold is the only place in the architecture where that asymmetry becomes executable code. Everything above it is engineering; this one line is management.

That is why the number should not live only in a config file. Write it down with a date, an owner, and a trigger for revisiting it. The trigger is not a calendar reminder; it is a change in the base rate, a change in the label set, or a change in who absorbs the loss. A threshold with no owner drifts, and drift is invisible right up until someone audits the queue.

Close

The line in the config file is the shortest policy document most companies have ever written, and almost nobody treats it that way. If you cannot say who chose the number, when, and what they were trading away, then it was not a policy. It was a guess with production access.

The fix is not a better number. It is a name next to the number, and a curve that says what the number buys.

If you are working on that joint — the confidence, the threshold, the report that is supposed to justify it — Decider answers one question with two candidate options, a pick, a calibrated confidence, and a written argument you can disagree with.

I Built My Own Database From Scratch — Meet CleaveDB

John David L. Perez — Sun, 04 Oct 2026 01:10:09 +0000

I Built My Own Database From Scratch — Meet CleaveDB

I've been building something I've wanted to experiment with for a while: CleaveDB.

CleaveDB is a hybrid relational-document graph database built with Python, Rust, and C++ SIMD, with its own query language, graph relationships, and built-in semantic search.

The idea started with a simple question:

What if relational data, documents, graphs, and semantic search could live together in one database?

What makes CleaveDB different?

CleaveDB has its own query language called CleaveQL.

For example:

POUR INTO users "alice" {
    "name": "Alice",
    "age": 28
}

You can then query the data:

SCOOP users

It also supports graph-style relationships called Bonds:

LINK "users:alice"
TO "users:bob"
AS MUTUAL "friend"

And you can traverse those relationships:

FIND "friend" OF "users:alice"

There's also semantic search:

FIND products
MEANING "something warm for cold weather"
LIMIT 3

So instead of searching only for exact keywords, CleaveDB can search based on meaning.

Under the hood

CleaveDB isn't built on top of an existing database engine. I'm building the storage layer myself using Rust, with C++ SIMD optimisations for performance-critical operations.

The project also includes:

B+Tree storage
WAL and transactions
Graph relationships
Semantic/vector search
Authentication and multi-tenant isolation
Python bindings
HTTP, WebSocket and TCP interfaces

It's still very much a work in progress, but building the pieces from scratch has been a really interesting learning experience.

Why build another database?

There are already excellent databases like PostgreSQL, MongoDB, Redis, and Neo4j.

I'm not trying to replace them.

CleaveDB is an experiment to see what happens when you combine relational, document, graph, and semantic capabilities into one system.

If you're interested in databases, Rust, storage engines, graph databases, or just want to see how a database is built from scratch, I'd love to hear your thoughts.

Tribrix23 / CleaveDB

Beyond NoSQL. A hyper-fast graph and vector database you query in plain English. Built on a unique Python, Rust, and C++ SIMD architecture with built-in AI semantic search and strict multi-tenant isolation.

The polyglot, AVX-512 ready , hybrid relational-document graph database with Transformer attention layers.

CleaveDB 3.9.0 is a ground-up, hybrid Relational Document & Graph database that eliminates the complexity of traditional SQL JOINs, external vector search services, and opaque graph databases. It ships with:

Native Graph-Relational Links: Documents are not isolated. They are deeply relational, linked natively through ~10 functional Graph "Bonds" that allow unlimited depth, multi-hop traversals with conversational English, completely eliminating the need for JOINs.
A high-performance Rust storage engine built entirely from scratch — no SQLite, no RocksDB, no external storage libraries.
AVX-512 / AVX2 C++ SIMD extensions exist in the Rust engine (vector search runs on C++ AVX-512 extensions).
A Python interpreter frontend (via PyO3 bindings) that runs the CleaveQL query language.
Real neural Transformer embeddings for semantic search via a quantized ONNX model, using ~22MB of RAM.
A Go-based distributed coordinator for multi-shard…

View on GitHub

I'm especially interested in criticism and ideas for what I should improve next.

A single pfSense block never becomes a Wazuh alert. Here is why, measured.

Nguyen Dong — Sun, 04 Oct 2026 01:08:44 +0000

You point pfSense at Wazuh, the logs arrive, and the dashboard stays empty. Most people assume the integration is broken. On Wazuh 4.14.7 it usually is not: there are two separate reasons, and one of them is by design.

We sent pfSense filterlog lines over UDP syslog to a Wazuh 4.14.7 manager container and read archives.log and alerts.json.

Reason 1: rule 87701 carries `no_log`

The stock pfSense rules live in ruleset/rules/0540-pfsense_rules.xml:

Rule	Level	Matches	Becomes an alert?
87700	0	any `filterlog` event decoded as `pf`	no (level 0)
87701	5	`action` = block	no: it has `<options>no_log</options>`
87702	10	18 × 87701 from one source IP within 45 s	yes

The comment above 87701 says: "We don't log firewall events, because they go to their own log file." Pass events stop at 87700.

What we measured:

One block line over UDP 514: it reached archives.log; alerts.json stayed empty.
18 block lines from one address within the window: the 18th came back as 87702, level 10.

So a working integration shows nothing until one address is blocked 18 times in 45 seconds.

One trap while testing: wazuh-logtest prints "Alert to be generated" for 87701 anyway. Logtest does not apply no_log. Check alerts.json, not logtest.

Reason 2: RFC 5424 lines match no decoder

pfSense can log in BSD (RFC 3164) or RFC 5424 format. The stock decoder is keyed on <program_name>filterlog</program_name>, which Wazuh's pre-decoder reads from a BSD-style header. Over UDP on 4.14.7:

Line sent	Decoder
`Oct 2 15:00:01 pfSense filterlog[12345]: 5,,,1000000103,igb1,match,block,…`	`pf`: srcip, dstip, action read
`2026-10-02T15:00:01.123456+07:00 pfSense.home.arpa filterlog[12345]: …`	`pf`: read
`<134>1 2026-10-02T15:00:01.123456+07:00 pfSense.home.arpa filterlog 12345 - - …`	No decoder matched

With RFC 5424, archives.log even shows the manager's own host name instead of the firewall's: the header was never parsed.

The fix

Send BSD format. In pfSense, Status → System Logs → Settings, set the log message format to BSD (RFC 3164).
Decide which blocks you want as alerts. To alert on every block, overwrite 87701 without no_log in /var/ossec/etc/rules/local_rules.xml:

<group name="local,pfsense,">
  <rule id="87701" level="5" overwrite="yes">
    <if_sid>87700</if_sid>
    <action>block</action>
    <description>pfSense firewall drop event.</description>
    <group>firewall_block,pci_dss_1.4,gpg13_4.12,hipaa_164.312.a.1,nist_800_53_SC.7,tsc_CC6.7,tsc_CC6.8,</group>
  </rule>
</group>

On 4.14.7 this loaded with no warnings, and the same single block line that produced nothing produced one 87701 alert. An internet-facing firewall blocks a lot, so many people prefer a narrower child rule (one interface, one port) and leave 87701 alone.

Limits

Measured on a Wazuh 4.14.7 manager container, with syslog over UDP from 127.0.0.1 and in wazuh-logtest. We did not run a pfSense box: the lines were written in the filterlog format for one IPv4 TCP block and one pass. Not measured: IPv6, other pfSense programs, OPNsense, other Wazuh versions.

Full note with the one-minute checks: https://atkvn.com/fix-pfsense-logs-not-showing-in-wazuh.html

Dong Nguyen, ATK New Technology. We check and fix Wazuh rules for people who run it.

StressFreeFantasy: Lineup Optimization with TabPFN and Real NFL Data

Lucas — Sun, 04 Oct 2026 01:07:11 +0000

This project is a submission for the Hacktoberfest: Build for a Friend DEV Challenge, targeting the **Best Use of TabPFN* category.*

1. Context & Motivation

Me and my brother play in the same competitive fantasy football league, which means my default setting on Sundays is actively rooting for his team to implode.

That said, watching him agonize every single week over two flex players projected within 0.3 points of each other got painful to witness.

Default platform projections have known limitations:

Static estimates: They rarely adjust quickly for game scripts (Vegas totals and spreads).
Positional matchups: Opponent defensive strength against specific positions is often averaged out or ignored.
Point estimates only: They show a single expected number rather than a distribution. In reality, whether you need a high floor (P10) to protect a lead or a high ceiling (P90) to chase upside completely changes who you should start.

I built StressFreeFantasy to automate these decisions. It syncs with private ESPN leagues, conditions an in-context tabular foundation model on historical NFL data, and outputs an optimized lineup with floor/ceiling estimates. (Though whether I let him use it against me when we play head-to-head remains an open question.)

2. Why TabPFN?

Standard tabular models (like XGBoost or LightGBM) require training pipelines, feature scaling, and hyperparameter tuning. More importantly, when leagues use non-standard scoring rules (Full PPR, Half PPR, TE premium, big-play bonuses), a traditional model has to be retrained from scratch for those specific point values.

TabPFN handles this differently:

In-Context Adaptation: As a prior-data fitted foundation model, it runs in-context learning in a single forward pass. By feeding it 2,000 historical NFL player-weeks recalculated to the user's specific scoring settings, TabPFN adapts instantly without gradient steps.
Quantile Outputs: TabPFN natively supports querying specific quantiles (quantiles=[0.1, 0.9]), providing calibrated P10 (floor) and P90 (ceiling) values rather than just a noisy mean.

Why Open Innovation Matters Here

Relying on an open-weight, locally runnable tabular foundation model makes all the difference compared to closed cloud APIs:

Zero API Cost & Unlimited Inference: Simulating thousands of matchup permutations and testing historical holdouts incurs zero per-token API charges.
Data Privacy: League authentication tokens (espn_s2, SWID) and private league rosters stay completely local on the user's machine—never routed through a third-party server.
Offline-Ready In-Context Learning: TabPFN runs locally on a consumer laptop CPU/GPU without depending on external proprietary server uptimes right before Sunday kickoffs.

3. Architecture & Data Pipeline

The project is built with Streamlit and ties together three data sources:

                    ┌────────────────────────────┐
                    │    nflverse / nflreadpy    │
                    │  5 Seasons Historical Data │
                    └─────────────┬──────────────┘
                                  │
                                  ▼
┌──────────────────────┐   ┌──────────────┐   ┌──────────────────────┐
│  Private ESPN League │──▶│   TabPFN     │──▶│ Streamlit Dashboard  │
│  (espn-api / S2&SWID)│   │ In-Context   │   │ Lineup + Floor/Ceil  │
└──────────────────────┘   │ Regressor    │   └──────────────────────┘
                           └──────────────┘

Feature Engineering

Features are computed without data leakage, using strictly pre-game rolling historical signals:

Player baseline: 16-game rolling average (Avg_Pts), previous week's score (Last_Week_Pts), and short-term form (Form_L3).
Volume: Rolling 3-game touches and targets (Volume_Proj), which is historically more stable than point totals.
Game environment: Opponent defensive ranking against the player's specific position (Opp_Def_Rank), dome status, and Vegas implied team total derived from over/under and point spread: $$\text{Implied Team Total} = \frac{\text{Vegas Total} + \text{Spread}}{2}$$

4. Benchmark & Validation

Fantasy projections have high variance due to random touchdown variance, making raw MAE an incomplete metric. What matters for a manager is whether the model ranks the right player higher in a head-to-head Start/Sit call.

We set up an out-of-time temporal test, fitting on earlier seasons and testing on an unseen holdout season ($N = 600$ test player-weeks):

Metric	Baseline (Avg)	Baseline (Form)	TabPFN (Ours)
MAE (lower is better)	6.84 pts	7.12 pts	5.91 pts
Correlation ($r$)	0.44	0.38	0.58
Pairwise Start/Sit Accuracy	52.8%	51.4%	63.7%

In pairwise head-to-head matchups between players at the same position, TabPFN selected the higher-scoring option 63.7% of the time.

5. Interface & Usage

The Streamlit UI provides:

ESPN Sync: Imports rosters, schedules, and custom scoring tables using league credentials (espn_s2, SWID).
Manual Adjustments: An interactive data editor to tweak expected volume, health status, or weather/stadium conditions.
Lineup Optimizer: Greedily fills position slots (QB, RB, WR, TE, FLEX) sorted by projected output and matchup edge.

6. Testing & Feedback

Since we play in the same league, I initially tested the engine on my own roster to see how the recommendations differed from ESPN's defaults. Rather than relying on a single static projection, having direct access to calibrated P10 (floor) and P90 (ceiling) intervals made marginal Start/Sit calls immediately clearer.

After seeing the floor/ceiling spreads and the pairwise accuracy numbers, I showed the tool to my brother to help him with his own weekly lineup headaches. He now uses it as a sanity check before kickoff rather than overthinking marginal calls—which unfortunately means his roster is noticeably harder to beat when we play each other.

7. Repository & AI Transparency

GitHub: lucasantonsson/StressFreeFantasy
Stack: Python, Streamlit, TabPFN, nflreadpy, espn-api
AI Collaboration: Code generation, pipeline scaffolding, and debugging were assisted by Claude and Gemini, while system design, logic requirements, and validation were directed independently.

DEV Community

Agents Don't Need Memory, They Need Documentation: A Practical AGENTS.md Playbook

Vì sao memory không giải quyết được vấn đề

Cấu trúc docs mà mình đang dùng

Tự sinh bản đồ repo thay vì viết tay

Chặn docs lỗi thời bằng CI

Kết luận

How We Structure a Small-Business CRM Database (Tables You'll Actually Need)

The core tables

Why this shape works

What we add later

Lovable Cloud to Supabase Migration Checklist

What actually lives in a Lovable Cloud project

The boring part (that still needs doing in order)

Three things that break after the switch

Google sign-in goes through Lovable

The AI features go quiet

Signup emails never arrive

The cron job nobody remembers

How the checker works (and where it's dumb)

Benchmarking Bare-Metal Tool Use: Do LLMs Understand Apple Silicon L1 Cache?

[derive(Serialize, Deserialize)]

[repr(align(64))] // WRONG: Triggers false sharing on Apple Silicon L1 (128-byte)

[repr(C, align(128))] // CORRECT: Apple Silicon M-Series L1 Cache-Line Aligned

CVE-2026-61500: Forging an HFS Admin Session Without Logging In

Root cause: Math.random() used where crypto belongs

Walking the attack chain

Steps 1–2: Harvest PRNG outputs

Step 3: Reverse the PRNG state

Step 4: Recover the cookie-signing key

Step 5: Forge the admin session

Step 6: RCE via server_code

The fix: real randomness

I Traced Unbound's DNSSEC Heap Overflow: 4 Checks to Run

What actually broke in the DNSSEC validator?

Why does a self-referencing pointer overflow a heap buffer?

Why is the second CVE about the encrypted transports?

The question most deployments get wrong

Which of your resolvers are actually Unbound or CoreDNS?

Where do resolvers hide in a typical stack?

What do the scores actually tell you here?

What should you check before you patch?

Should the score or the blast radius drive the queue?

Add an FAQ bot and appointment booking to any website with 3 API calls

0. Try it right now (no account)

1. Set up the business (2 minutes)

2. Answer a question

3. List open times and book one

4. A tiny website widget (server route + 30 lines of JS)

Limits, honestly

Webwright ของ Microsoft: ให้ AI เขียนโค้ดท่องเว็บ แทนที่จะนั่งคลิกทีละครั้ง

Webwright ของ Microsoft: ให้ AI เขียนโค้ดท่องเว็บ แทนที่จะนั่งคลิกทีละครั้ง

ปัญหาที่ทุกคนที่สร้าง agent เจอ แต่ไม่ค่อยมีใครตั้งชื่อให้มัน

แนวคิด: แยก agent ออกจาก browser

ข้างในมีแค่สามชิ้น

ตัวเลขที่ทำให้ต้องหยุดอ่าน

อะไรที่ยังต้องระวัง

จุดที่งานนี้ไปไกลกว่าที่คิด

อะไรที่คนไทยเอาไปใช้ได้จริง

สี่ข้อที่ผมว่าคุ้มที่สุดสำหรับทีมเล็ก

คำถามที่ต้องถามก่อนเชื่อ

ที่ควรไปอ่านต่อ

เอกสารอ้างอิง

A threshold is a policy, not a number

A threshold is a policy, not a number

What the joint is switching between

Where the 0.8 came from

Both directions are expensive; only one is invisible

The curve has to exist before the latch means anything

Three questions before you trust the latch

A parameter gets tuned; a policy gets defended

Close

I Built My Own Database From Scratch — Meet CleaveDB

What makes CleaveDB different?

Under the hood

Why build another database?

Tribrix23 / CleaveDB

Beyond NoSQL. A hyper-fast graph and vector database you query in plain English. Built on a unique Python, Rust, and C++ SIMD architecture with built-in AI semantic search and strict multi-tenant isolation.

A single pfSense block never becomes a Wazuh alert. Here is why, measured.

Reason 1: rule 87701 carries no_log

Reason 1: rule 87701 carries `no_log`