georgecalm

I really appreciate that someone's job (or at least part of it) was to "prototype concepts that would add some interactive sparkle to the site". Working on a larger team, we generally add this kind of interaction at the start of a project or during redesign. There are larger prototypes, of course. But very rarely is someone designated to independently go out and just find small ways of making the experience just a bit nicer for the users, and build that; and I really like that idea.

Is there any evidence for the codebase having no tests? I wouldn’t expect those to come through in the source map.

Intersected available info on the web with the source for this list of new features:

UNRELEASED PRODUCTS & MODES

1. KAIROS -- Persistent autonomous assistant mode driven by periodic <tick> prompts. More autonomous when terminal unfocused. Exclusive tools: SendUserFileTool, PushNotificationTool, SubscribePRTool. 7 sub-feature flags.

2. BUDDY -- Tamagotchi-style virtual companion pet. 18 species, 5 rarity tiers, Mulberry32 PRNG, shiny variants, stat system (DEBUGGING/PATIENCE/CHAOS/WISDOM/SNARK). April 1-7 2026 teaser window.

3. ULTRAPLAN -- Offloads planning to a remote 30-minute Opus 4.6 session. Smart keyword detection, 3-second polling, teleport sentinel for returning results locally.

4. Dream System -- Background memory consolidation (Orient -> Gather -> Consolidate -> Prune). Triple trigger gate: 24h + 5 sessions + advisory lock. Gated by tengu_onyx_plover.

INTERNAL-ONLY TOOLS & SYSTEMS

5. TungstenTool -- Ant-only tmux virtual terminal giving Claude direct keystroke/screen-capture control. Singleton, blocked from async agents.

6. Magic Docs -- Ant-only auto-documentation. Files starting with "# MAGIC DOC:" are tracked and updated by a Sonnet sub-agent after each conversation turn.

7. Undercover Mode -- Prevents Anthropic employees from leaking internal info (codenames, model versions) into public repo commits. No force-OFF; dead-code-eliminated from external builds.

ANTI-COMPETITIVE & SECURITY DEFENSES

8. Anti-Distillation -- Injects anti_distillation: ['fake_tools'] into every 1P API request to poison model training from scraped traffic. Gated by tengu_anti_distill_fake_tool_injection.

UNRELEASED MODELS & CODENAMES

9. opus-4-7, sonnet-4-8 -- Confirmed as planned future versions (referenced in undercover mode instructions).

10. "Capybara" / "capy v8" -- Internal codename for the model behind Opus 4.6. Hex-encoded in the BUDDY system to avoid build canary detection.

11. "Fennec" -- Predecessor model alias. Migration: fennec-latest -> opus, fennec-fast-latest -> opus[1m] + fast mode.

UNDOCUMENTED BETA API HEADERS

12. afk-mode-2026-01-31 -- Sticky-latched when auto mode activates 15. fast-mode-2026-02-01 -- Opus 4.6 fast output 16. task-budgets-2026-03-13 -- Per-task token budgets 17. redact-thinking-2026-02-12 -- Thinking block redaction 18. token-efficient-tools-2026-03-28 -- JSON tool format (~4.5% token saving) 19. advisor-tool-2026-03-01 -- Advisor tool 20. cli-internal-2026-02-09 -- Ant-only internal features

200+ SERVER-SIDE FEATURE GATES

21. tengu_penguins_off -- Kill switch for fast mode 22. tengu_scratch -- Coordinator mode / scratchpad 23. tengu_hive_evidence -- Verification agent 24. tengu_surreal_dali -- RemoteTriggerTool 25. tengu_birch_trellis -- Bash permissions classifier 26. tengu_amber_json_tools -- JSON tool format 27. tengu_iron_gate_closed -- Auto-mode fail-closed behavior 28. tengu_amber_flint -- Agent swarms killswitch 29. tengu_onyx_plover -- Dream system 30. tengu_anti_distill_fake_tool_injection -- Anti-distillation 31. tengu_session_memory -- Session memory 32. tengu_passport_quail -- Auto memory extraction 33. tengu_coral_fern -- Memory directory 34. tengu_turtle_carbon -- Adaptive thinking by default 35. tengu_marble_sandcastle -- Native binary required for fast mode

YOLO CLASSIFIER INTERNALS (previously only high-level known)

36. Two-stage system: Stage 1 at max_tokens=64 with "Err on the side of blocking"; Stage 2 at max_tokens=4096 with <thinking> 37. Three classifier modes: both (default), fast, thinking 38. Assistant text stripped from classifier input to prevent prompt injection 39. Denial limits: 3 consecutive or 20 total -> fallback to interactive prompting 40. Older classify_result tool schema variant still in codebase

COORDINATOR MODE & FORK SUBAGENT INTERNALS

41. Exact coordinator prompt: "Every message you send is to the user. Worker results are internal signals -- never thank or acknowledge them." 42. Anti-pattern enforcement: "Based on your findings, fix the auth bug" explicitly called out as wrong 43. Fork subagent cache sharing: Byte-identical API prefixes via placeholder "Fork started -- processing in background" tool results 44. <fork-boilerplate> tag prevents recursive forking 45. 10 non-negotiable rules for fork children including "commit before reporting"

DUAL MEMORY ARCHITECTURE

46. Session Memory -- Structured scratchpad for surviving compaction. 12K token cap, fixed sections, fires every 5K tokens + 3 tool calls. 47. Auto Memory -- Durable cross-session facts. Individual topic files with YAML frontmatter. 5-turn hard cap. Skips if main agent already wrote to memory. 48. Prompt cache scope "global" -- Cross-org caching for the static system prompt prefix

> This is the most expensive failure mode with AI-assisted coding, and it’s not wrong syntax or bad logic. It’s implementations that work in isolation but break the surrounding system.

This is spot on. Zooming out, a perfectly written implementation that follows all the conventions but misses the mark on its business goal is as, if not more, expensive. I think adding a brief.md artifact to the beginning of the flow (where you store the problem, desired change, primary metric, feature-kill criteria) can go a long way.

There's a great video from "Technology Connections" covering one-pedal driving here [1]. The gist of it is that one-pedal breaking doesn't have a great way to control the break lights, making it difficult for the cars behind you to recognize that you're slowing down, which can cause accidents.

[1] https://youtu.be/U0YW7x9U5TQ?si=7XFO_ZHIwUjd-3Sm&t=195

Thank you for putting the list together! If I may make a suggestion, what you wrote above would be an excellent first paragraph in the readme, as it explains the intent well and the criteria for how you add books to the list.

If you'd like to use something like this in your own APIs to let your clients filter requests or on the CLI (as is the intention with gron), consider giving "json-mask" a try (you'll need Node.js installed):

  $ echo '{"user": {"name": "Sam", "age": 40}}' | npx json-mask "user/age"
  {"user":{"age":40}}

or (from the first gron example; the results are identical)

  $ gron "https://api.github.com/repos/tomnomnom/gron/commits?per_page=1" | fgrep "commit.author" | gron --ungron
  $ curl "https://api.github.com/repos/tomnomnom/gron/commits?per_page=1" | npx json-mask "commit/author"

If you've ever used Google APIs' `fields=` query param you already know how to use json-mask; it's super simple:

  a,b,c - comma-separated list will select multiple fields
  a/b/c - path will select a field from its parent
  a(b,c) - sub-selection will select many fields from a parent
  a/*/c - the star * wildcard will select all items in a field

Yesterday’s thread on the RC release: https://news.ycombinator.com/item?id=23875541

> Where should I start in a migration?

> Start by running the migration helper on a current project. We’ve carefully minified and compressed a senior Vue dev into a simple command line interface. Whenever they recognize an obsolete feature, they’ll let you know, offer suggestions, and provide links to more info.

Vue's docs are a masterclass in docs-writing, imho. Clear. Concise. Empathetic. Written for humans.

I think the difference is that the browser already contains the shadow dom needed to render the video tag. But for a custom tag it would need to fetch, parse and execute your component code before it can begin to render.

I’m excited about this. There’s usually a ton unnecessary CPU usage with the current techniques, not to mention the human time waste of re-implementing them in JS. There’s feature detection for this too, so we can gracefully degrade “loading” to existing solutions and take advantage of it right away.

Great news for PWAs buried in the release notes: “Updated the behavior of websites saved to the home screen on iOS to pause in the background instead of relaunching each time.”

> What is a Toshi?

> Toshi is a three year old Shiba Inu. He is a very good boy and is the official mascot of this project. Toshi personally reviews all code before it is commited to this repository and is dedicated to only accepting the highest quality contributions from his human. He will though accept treats for easier code reviews.

There are two requirements that I personally don’t feel very comfortable with: the first one is uploading a picture of my ID (How is it stored / backed up. Who has access: third party validator or your team?) and the other is adding logmein to let a proctor control my machine prior to the exam. I saw that one may take the exam in person. I don’t know if it’s allowed by your rules, but I suppose I can set up a VM for this, but either way that just makes it more difficult for me to justify finding the time to do it.

- nuxt (or next if you prefer react) - tailwind (atomic css)

- node - express - passport (Use cookie based auth keeping the session in your storage. I wouldn’t waste time on JWT. There’s a decent amount of complexity if you want both the security of being able to revoke access to a bad actor and the convenience of long lived sessions, and at the end the auth server will most likely need to access storage and use cookies for that anyway (eliminating the benefits of JWT). So I’d start with cookie based auth and build up complexity as needed.)

- postgres - On the Node side, I don’t recommend adding the complexity of an ORM at first (or ever). The node pg driver will give you arrays of objects back for rows. It’s convenient enough not to need the extra overhead of an ORM. - As a side note, Postgres has modules for you to implement a decent first version of a lot of things, such as search for example, before you need to reach for a dedicated solution. This makes it amazing for startups in my opinion, as you can explore ideas very quickly.

- statsd / grafana (to monitor your app and learn from the behavior of your users)

- docker-colpose.yml to make spinning up your dev environment with node / db / stats as simple as “docker-compose up”

- DigitalOcean for hosting - Use their dokku image - Set up daily backups to Spaces since your DB will be hosted here at first too

- dokku for deployment with the Postgres, letsencrypt and grafana modules - deployments are as easy as “git push master dokku”

No surprises here this year: es6 & typescript, react & vue. I think I’d put redux and graphql in different categories as they’re not mutually exclusive. Nevertheless, I’m happy to see excitement for the latter.

Structured design by W.P. Stevens, G.J. Myers, and L.L. Constantine

I follow the check-in model from Adobe [1]. It isn’t a hard set of requirements, but is more of a set of topics that help guide the conversation. It’s especially helpful as a starting point for people new to management, like myself.

A check-in meeting is made up of three parts: (1) setting expectations, (2) providing feedback, (3) having a development conversation.

Status reports are explicitly not a part of this conversation. Those are easy to talk about, but have little value for your employee, and if you’re already doing daily stand-ups, they have little value for you too.

The first two topics are fairly self-explanatory, yet take time to learn to do well. The expectations must be clear, finite and actionable. Much has been written about the art and science of giving good feedback. I use a model where we talk about the Specific thing that happened, followed by Asking questions to understand their perspective, talking about the Impact of their actions on themselves and the people they have affected, and finally talking about what I expect them to Do now or in the future. (aka SAID)

The development conversation is the time for you to listen. This is where you learn about the professional skills they are working on growing (whether it’s public speaking, a particular career path or, say, a machine learning course, to name a few) and finding ways to help and facilitate those. If done right, you learn a lot about the person, their goals, aspirations, and will be in a better position to make a positive meaningful impact on their life.

The check-in is most effective if it’s guided by the employee. This encourages people to come with topics they care about and gives them the ability to focus more time on a particular aspect of the meeting which may be more important at that time.

1. https://www.adobe.com/check-in.html

I think it's a beautiful, thought out, polished and well built set of UI components. If that's what I needed for my next project, I wouldn't hesitate to use it. The docs are excellent too. There's so much attention to detail here. There's an immense amount of love poured into this project, even the code snippets are interactive.

You may like https://techyaks.com — it’s a site with over 80K software development tech talks ranked algorithmically.