Skip to content
WILLIAM / SOFTWARE · SYSTEMS

I build software with clear boundaries and reproducible tests.

I turn product ideas into working software — covering on-device iOS media processing, static security analysis, and local speech automation. I document what works, what failed, and what remains unfinished.

62/62
Tests Passed
EchoReel iOS Test Suite
50-case
Security Benchmark
SCSA Slither50 Suite
160/160
Soak Tasks Passed
VoiceFlow 8h Soak Test
CORE PRINCIPLES
“AI speeds up prototyping. Trust still comes from explicit boundaries, reproducible test runs, and the discipline to discard what fails in practice.”
Reject by default when checks failKeep sensitive data strictly localDisclose benchmark gaps and negative results
01FEATURED PROJECT · 01

EchoReel

On-device photo memories with manual confirmation for face groups.

DESIGN PRINCIPLE

“Suggest candidates automatically. Let people confirm identities.”

Problem

Cloud photo services upload private photos to remote servers and group people using opaque algorithms. EchoReel runs indexing and video generation entirely on the phone with zero network access.

Architecture

Processing is split with Swift actors: Apple Vision detects faces and proposes tentative groups, but the app cannot link photos in the SQLite database until the user taps confirm in the review queue.

Test Suite
62/62 PASS
3/3 UI simulator flows
Memory Budget
0.215 MiB
Ceiling: ≤0.250 MiB/photo
SYSTEM ARCHITECTURE · DATA FLOW & PRIVACY BOUNDARY

On-Device Photo & Face Processing Pipeline

Zero Network Requests
01 PhotoKit

01. Input: PhotoKit loads photos directly from the local library into device memory with no network access.

02 Apple Vision

02. Face Detection: Apple Vision finds face locations and extracts lightweight visual features locally.

03 Suggestions

03. Candidate Groups: Groups faces into tentative suggestions only. The system cannot confirm matches on its own.

04 Review QueueHuman Gate

04. Manual Review: The user confirms or rejects suggested face groups in a SwiftUI review screen.

05 Local SQLite

05. Storage: SQLite saves confirmed identities and memory collections within a 0.215 MiB/photo memory budget.

06 AVFoundation

06. Video Export: AVFoundation compiles and encodes photos into an animated video file locally.

Selected Step:01. Input: PhotoKit loads photos directly from the local library into device memory with no network access.
EVALUATION GATE LOG · ECHOREEL-021
GATE FAILED · NOT PROMOTED
Candidate Artifact
Candidate Face Embedding Model
Target Gate
Recall@50 ≥ 0.850000
Measured Result
0.585117 (-0.264883)
DECISION: The embedding candidate failed the recall threshold. Rather than accepting false groupings or masking errors, the model was discarded. The prototype continues with Apple Vision face observations paired with manual confirmation.
02FEATURED PROJECT · 02
PIPELINE ARCHITECTURE · DATA FLOW & SECURITY BOUNDARY

Static Screening & Grounded Explanation Flow

Native Builds Disabled by Default
01 Ingestion

01. Ingestion: Reads untrusted Solidity files with path protection; native compiler build scripts are turned off by default.

02 Slither AST

02. Static Analysis: Runs 27 mapped Slither rules, producing AST line spans and call graphs.

03 Normalizer

03. Normalization: Maps detector findings into unified schemas with standard CWE/SWC vulnerability IDs.

04 Evidence DBEvidence Anchor

04. Local Database: Saves verified findings and code locations in SQLite as concrete reference records.

05 Grounded LLM

05. Explanations: The local LLM explains code issues and drafts fixes using only the confirmed findings from the database.

Selected Step:01. Ingestion: Reads untrusted Solidity files with path protection; native compiler build scripts are turned off by default.
EVALUATION GATE LOG · SCSA-BENCH-02
MEASURED LIMITATION · 4 FALSE POSITIVES
Candidate Artifact
Slither50 v2 Automated Screening
Target Gate
Zero False Negatives (Recall 100.00%)
Measured Result
25 TP · 21 TN · 4 FP · 0 FN
LIMITATION: The benchmark produced 4 false positives on reentrancy and delegatecall rules. SCSA is designed and documented as a triage assistant for developers, not an automated security certification or replacement for manual audits.

Smart Contract Security Assistant

Static vulnerability screening with evidence-grounded explanations.

DESIGN PRINCIPLE

“Static analyzers identify code issues. LLMs explain and draft fixes.”

Problem

Large language models frequently hallucinate non-existent vulnerabilities or miss subtle logic flaws in smart contracts. Security reviewers need reliable screening without confusing language model fluency with security proof.

Architecture

Native compiler builds are disabled by default for safety. SCSA runs 27 mapped Slither static analysis rules, saves structured findings in a local SQLite database, and strictly restricts the LLM to explaining confirmed findings. Unmapped tool output is kept as raw text.

Test Suite
175 PASS
140 pytest + 35 Vitest
Slither50 v2 Benchmark
100% Recall
86.21% Precision · F1 92.59%
03FEATURED PROJECT · 03

VoiceFlow

Local-first macOS voice assistant with physical confirmation for system actions.

DESIGN PRINCIPLE

“No silent external actions. Ambiguous commands stop and ask.”

Problem

Voice tools that run system commands risk accidental file deletion or unintended actions when speech recognition misinterprets a phrase. Streaming room audio to cloud APIs also compromises desktop privacy.

Architecture

Commands are split into two paths: read-only queries answer immediately, while actions that modify state (deleting files, terminal scripts, posting online) require pressing a physical confirmation button. A background watchdog restarts crashed workers in 0.43 seconds.

8-Hour Soak Test
160/160 PASS
0.12 MB/hr memory slope
Safety Benchmark
0 Auto-Submits
0 unconfirmed destructive actions
COMMAND PIPELINE · PRIVACY & CONFIRMATION BARRIER

Local Voice Input to Verified macOS Action

0.43s Watchdog Recovery
01 Capture

01. Audio Input: Push-to-talk hotkey captures microphone audio into memory with zero cloud transmission.

02 Whisper STT

02. Local Speech-to-Text: Local faster-whisper CPU int8 transcribes audio (p50: 2,003 ms) without network requests.

03 Term Normalizer

03. Term Normalization: Rules fix common tech jargon and zh-TW phrasing errors in the transcript.

04 Intent Routing

04. Intent Classification: Separates simple read-only queries from actions that change system state.

05 Confirmation HUDConfirmation Gate

05. Confirmation Barrier: Actions that modify files or make network calls require explicit confirmation (0 auto-submits over 160 soak tests).

06 Worker & Audit

06. Execution & Logs: Executes the confirmed action. Watchdog restarts crashed workers in 0.43s. Logs are encrypted with AES-GCM in local SQLite.

Selected Step:01. Audio Input: Push-to-talk hotkey captures microphone audio into memory with zero cloud transmission.
EVALUATION GATE LOG · VF-STT-03
GATE FAILED · NOT PROMOTED
Candidate Artifact
Fine-tuned Whisper int8 (CTranslate2)
Target Gate
Relative WER Gain > 10% & Action Acc ≥ 0.90
Measured Result
WER +0.019188 · Action +0.0727
DECISION: Fine-tuning on local audio showed minor accuracy gains (+0.0727) and introduced boundary timing glitches. The candidate model was discarded; the application keeps the base Whisper model paired with a custom terminology dictionary.
DEVELOPMENT WORKFLOW

How I Work

A structured five-step workflow from requirements to test verification and honest review.

01STAGE

DEFINE

Identify constraints, user requirements, and testable acceptance targets before writing code.

Artifact: Requirements & Invariants
02STAGE

ARCHITECT

Map data boundaries, storage schemas, and security assumptions across components.

Artifact: Architecture Schemas
03MAIN WORKFLOW

BUILD

Implement modules with typed interfaces, local data stores, and clean component pipelines.

Artifact: Working Codebase
04STAGE

VERIFY

Run automated test suites, memory profiling, and edge-case test runs.

Artifact: Test Runs & Traces
05STAGE

ITERATE

Evaluate real benchmark results. Keep what meets the bar, discard failed models, and document limits.

Artifact: Decision & Drop Log
SECONDARY EXPERIMENTS & BENCHMARKS

Research & Experiments

Short engineering notes exploring workflow rules, local container environments, and evaluation harnesses.

Secondary research records with explicit boundaries and documented stop conditions.

EXP-01PAUSED RESEARCH

GovernSeed: Workflow Guardrails & Checklists

Machine-checked rules and pass/fail gates to constrain multi-step coding workflows.

Rule SchemasPass/Fail ChecksWorkflow ConstraintsLocal Testing
01 · Question

Can multi-step coding workflows be kept within repo boundaries using machine-checked schemas and automated checklists?

02 · What Was Built & Tested

Wrote rule schemas, local test scripts, and gate checklists to prevent automated edits from modifying files outside designated directories.

03 · Result

R1 checks successfully blocked unauthorized file edits and unconstrained side-effects across 12 test iterations.

04 · Limitations & Stop Conditions

Round R2 stopped at Gate G2: automated tests could not reliably detect semantic changes without manual review. The experiment was paused once evidence showed automated checks were insufficient.

05 · What Was Learned

Automated checks cannot verify semantic intent; validation rules must remain external, deterministic, and strict.

EXP-02RESEARCH LAB

Selfhosted Lab: Local Container Stacks & zh-TW Localization

Comparative setup and evaluation of 30 open-source tools running locally on Docker.

30 Systems TestedDocker Composezh-TW LocalizationMemory Profiling
01 · Question

How do common open-source self-hosted services perform locally under container isolation and Traditional Chinese localization?

02 · What Was Built & Tested

Configured Docker Compose stacks, environment templates, zh-TW language packs, and health check scripts for 30 self-hosted services.

03 · Result

Measured baseline memory usage (42 MB to 1.8 GB idle), recorded missing translation strings in 14 tools, and documented database setup steps.

04 · Limitations & Stop Conditions

Tested on localhost only. Mail deliverability, public DNS configuration, multi-tenant setup, and production scale were out of scope. No private keys or personal data stored.

05 · What Was Learned

Reproducible setups require pinned container images and clean volume mounts; translation coverage varies widely regardless of project star counts.

EXP-03PAUSED RESEARCH

OSS Benchmark V3/V4: Test Runner Harness

Harness engineering with clean workspace states, independent test oracles, and runner isolation.

Clean FixturesIndependent OraclesProcess IsolationZero False Claims
01 · Question

Can code-generation tools be evaluated on software tasks without test leakage or runner contamination?

02 · What Was Built & Tested

Built reproducible test fixtures, sealed git workspaces, task schemas, and independent test oracles decoupled from the generator context.

03 · Result

V3 ran 40 baseline challenges with reproducible outputs. V4 added Linux cgroups to enforce memory limits and clean process teardown.

04 · Limitations & Stop Conditions

V4 was paused before live runs: clean cgroup teardown across edge-case kernel configurations could not be guaranteed. With 0 pilot runs run, no performance claims are made.

05 · What Was Learned

Benchmark credibility requires reliable test isolation; pausing the run when containment is uncertain is better than publishing contaminated results.