Lindsay Holmwood auxesis

Member-facing language — no acronyms

Never present acronyms or initialisms in text shown to a user — spell them out. Acronyms are coded jargon that make the app harder for new SES members to understand. Capability labels in capabilities.json (and any UI copy) use the full name: "Urban Search and Rescue" not "USAR", "Alpine Search and Rescue" not "Alpine SAR". This applies even where an acronym was used historically. (Org/product names like "SES" and "aXcelerate", and the source-data UoC codes themselves, are not the target — this is about descriptive labels and prose.) Known outstanding violation: the report still uses "FFR" ("By FFR", "Missing FFR") for "Fit for Role" — flag/track a cleanup

name	reviewing-infracode
description	Use when the user asks to "review this branch / PR / diff" and the changes touch infrastructure-as-code — Terraform, CloudFormation, mise tasks, observability configs (Prometheus, YACE, Grafana), or anything under `infra/`. Focuses on maintainability, readability, similarity to sibling stacks, and the quiet-but-expensive Terraform pitfalls that don't show up in `plan`.

Reviewing Infracode

When to use

The user asks for a review of a branch, PR, or diff, AND the changes are infrastructure-as-code: Terraform (*.tf), CloudFormation (*.yaml/*.yml under infra/), mise task definitions (mise*.toml), observability configs (prometheus.yml, yace.yml, alert rules, dashboards), or anything else under an infra/ tree.

Searching the unsearchable: how we made encrypted JSON searchable

Speaker: Lindsay Holmwood

When protecting sensitive data in our apps, everyone uses the same tried-and-true approach: build layers of controls around that data. But there is always a constraint: sensitive data must be stored in plaintext. What if we could encrypt it and perform range, match, and unique queries without ever decrypting it?

In this talk you will learn:

Title

Protecting sensitive data in DynamoDB with searchable encryption

Description

As architects, data security is a non-negotiable attribute of our solution designs. The traditional go-to technique to protect data is to build layers of controls around sensitive data. But there is always a constraint: sensitive data must be stored in plaintext. Why don’t we encrypt it? Because we can’t use it.

But what if we could encrypt it and perform range, match, and unique queries without ever decrypting it? This would allow us to exceed the design principles of the Security Pillar and protect data in transit, at rest, and in-use.

	#!/usr/bin/env bash
	#
	# test-gap-review — portable test-coverage gap reviewer for ANY git repo.
	#
	# Switches the current checkout to a PR (or branch) — safely, even inside a
	# git worktree — then runs Claude Code headless to find test-coverage gaps in
	# the changed code. BY DEFAULT it reviews but does NOT post: it prints the
	# review, then asks for confirmation before posting to the PR.
	#
	# Language-agnostic: it does not assume Rust/Go/TS/etc. Claude detects the

	#!/bin/sh
	#
	# pre-push hook: refuse to push if any commit being pushed is unsigned.
	# A commit is considered unsigned when git's %G? placeholder reports 'N'.

	# All-zeros OID of the correct length for this repo's hash algorithm.
	zero=$(git hash-object --stdin </dev/null \| tr '0-9a-f' '0')

	unsigned=""

	{
	"commands": [
	{
	"name": "completion",
	"description": "Generate the autocompletion script for the specified shell"
	},
	{
	"name": "controls",
	"description": "Fetch controls",
	"flags": [


	type Users struct {
	id uuid
	email string `cs:indexes:["free_text_search","equality","order_and_range"]`
	}

	type Photos struct {
	id uuid
	created_at time.Time `cs:indexes:["equality","order_and_range"]`
	}

	#!/bin/sh
	#
	# ## Setup
	#
	# Install hueadm:
	#
	# ```bash
	# npm install -g hueadm
	# ```
	#

	#EXTM3U
	#EXTVLCOPT:http-referrer=https://www.surfline.com/
	#EXTVLCOPT:http-user-agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/117.0
	https://hls.cdn-surfline.com/east-au/au-umina/playlist.m3u8