Tom monotykamary

Event-Sourced RBAC Audit Log

WITHOUT IT:

  Agent A (tenant X)          Agent B (tenant Y)          Agent C (tenant X)
     │                           │                           │
     │  "read file /data/db"     │  "exec rm -rf /tmp"       │  "query customers"
     ▼                           ▼                           ▼
  ┌─────────┐                ┌─────────┐                ┌─────────┐

Design a data structure that follows the constraints of a Least Recently Used (LRU) cache.

LRUCache(capacity int) Initialize the cache with positive size capacity.
int get(int key) Return the value of the key if it exists, otherwise return -1.
void put(int key, value int) Update the value of the key if it exists. Otherwise, add the key-value pair to the cache. If the number of keys exceeds the capacity, evict the least recently used key.
Both get and put must run in O(1) average time complexity.

type LRUCache struct {
    // TODO: design your structs
}

Concurrent Data Pipeline with Backpressure

Implement a high-throughput data processor in Go that simulates the FireGroup analytics workload:

// ProcessData ingests items from a source channel, transforms them via a CPU-intensive 
// operation (simulate with time.Sleep), and sends to a sink. Requirements:
// 1. Process up to N items concurrently (worker pool), but limit total concurrent processing 
//    to prevent OOM under load (backpressure)
// 2. Implement graceful shutdown on context cancellation: finish in-flight items,

Thread-Safe LRU Cache with TTL

Implement an in-memory LRUCache class in Ruby. It must support O(1) get and put operations. You need to handle production realities:

Requirements:

get(key) → Returns value or nil if key doesn't exist or is expired.
put(key, value, ttl_seconds) → Inserts/updates. Evicts least recently used if capacity exceeded. TTL is per-key expiration.
Thread-safe: Multiple threads can safely call get/put concurrently.
Expiration happens lazily (on access) or proactively (bonus points).

Given the root of a binary tree, return the level order traversal of its nodes' values (i.e., from left to right, level by level). [1, 2]

Example 1:

Input: root = [3,9,20,null,null,15,7]
Output: [[3],[9,20],[15,7]] [1, 3, 4, 5, 6]

Example 2:

Input: root = [1]

# frozen_string_literal: true

# Reward Aggregator
# Partners return inconsistent key types: some JSON APIs return strings,
# internal services return symbols. Result must unify them.

GRAB_PARTNER = {
  'reward_a' => { 'points' => 5000, 'key' => 'gr-a', 'tier' => 'silver' },
  'reward_b' => { 'points' => 7500, 'key' => 'gr-b' },

Letta Code Memory Architecture Deep Dive

A comprehensive technical breakdown of how memory works in Letta Code

Playwright MCP Context Optimization Guide

This document describes how to reduce context overflow when using Playwright MCP with LLMs. A single tool call can produce 400k+ tokens due to ads, trackers, cookie banners, and verbose page snapshots. These optimizations can reduce that by 80-90%.

Problem Statement

Playwright MCP returns full page snapshots (accessibility tree in YAML format) after every action. This causes:

Token overflow: 400k+ tokens per tool call on complex pages
Wasted context: Ads, trackers, cookie banners inflate content
Unnecessary data: Most actions don't need the resulting snapshot

	-- Pi HTTP Request Analysis
	-- Counts all outbound HTTP requests: assistant API calls + tool calls

	INSTALL json;
	LOAD json;

	-- Create a table from all JSONL session files
	CREATE OR REPLACE TABLE events AS
	SELECT * FROM read_json_auto('agent/sessions//.jsonl', format='newline_delimited', ignore_errors=true, maximum_object_size=134217728);

	echo "=== WITHOUT tools ==="
	curl -s --max-time 30 "https://pass.wafer.ai/v1/chat/completions" \
	-H "Authorization: Bearer $WAFER_API_KEY" \
	-H "Content-Type: application/json" \
	-d '{
	"model": "GLM-5.1",
	"messages": [
	{"role": "system", "content": "You are a helpful assistant."},
	{"role": "user", "content": "Read the file /tmp/test.txt"}
	],