I build local-first products, AI/agent runtimes, and Apple-platform systems where the hard part is not "using AI", but making the workflow observable, repeatable, recoverable, and useful under real constraints.

My work usually starts from raw material: repos, logs, device behavior, user flows, browser output, release pipelines, and long-lived product maintenance. The result I care about is a system that can be inspected, rerun, debugged, shipped, and explained.

RonnieCC is the public index of my projects and writing. GitHub is where many of the implementation surfaces, runtime experiments, and product-support repos live.

• LLM and agent runtimes: session continuity, workspace binding, failure recovery, context restoration, tool boundaries, and reviewable intermediate state.
• Local-first AI products: Apple-platform reading, capture, indexing, and inference workflows designed around real context-window, token-budget, privacy, and device constraints.
• Media and tvOS runtimes: playback stability, source volatility, plugin boundaries, HLS/transmux edge cases, Apple TV focus, and long-term product maintenance.
• Observable workflows: turning debugging, publishing, SEO, design review, and AI collaboration into repeatable flows with visible evidence.
• Distribution systems: making content, docs, changelogs, project pages, and support surfaces readable by people, search engines, and agents.

Local-first AI reading for macOS, iOS, iPadOS, and Safari Extension.

The interesting part is not a summary button. It is a structure-first reading workflow with bundled WebLLM popup inference, native app boundaries, token-aware long-document processing, and Apple-platform product constraints.

Surface: public Swift repo, App Store product, Safari Extension, local inference workflow.

Long-running Apple TV media runtime and product ecosystem.

Syncnext is built around explicit boundaries: the native tvOS app owns the product and interaction surface; SyncnextHybrid isolates AetherEngine, native AVKit presentation, proxy-timeline authority, and audio analysis; source data, parsing, routing rules, and plugin contracts live in external support surfaces.

Surfaces: SyncnextHybrid, syncnext-api, syncnextPlugin, SyncnextClash, product docs and changelog.

Workspace-first Codex runtime for binding remote messages to real local workspaces and existing Codex sessions.

The goal is not a chatbot wrapper. It is a desktop-owned runtime with Telegram as an adapter, local management surfaces, session repair, workspace state, release packaging, and continuation across machines and contexts.

Surface: public Rust repo, macOS release pipeline, Telegram-to-Codex session continuity.

My public project and writing index.

RonnieCC is also a distribution system: Notion remains a material source, while the public site turns projects, posts, static pages, sitemaps, canonical URLs, and downstream mirrors into a verifiable publishing contract.

Surface: public site, static build, project index, blog sync, sitemap and distribution workflow.

Practical Codex workflow skills extracted from repeated real work.

These are not prompt snippets. They capture workflows for context recovery, debugging discipline, model consultation, content handoff, and browser-visible validation so the same kind of work can start from a better default next time.

Surface: public Python repo, installable Codex skills, RonnieCC writing.

Local-first, white-box AI video pipeline for turning a news source into a branded YouTube Short.

The public Python pipeline coordinates story preparation, speech, A/B-roll production, word-level subtitles, branding, and an optional YouTube upload step. The repo publishes architecture, automation code, module specifications, design notes, and operational runbooks while keeping credentials, model weights, private media, and machine-specific assets outside the public snapshot.

Surface: security-reviewed MIT source snapshot, four-stage pipeline runbooks, RonnieCC project notes, and demo material. It is an engineering reference, not a turnkey model or content bundle.

I tend to turn messy work into systems through the same loop:

1. Start from evidence: repo state, logs, browser output, data files, device behavior, or publishing surfaces.
2. Find the boundary: what should be native, external, generated, cached, reviewed, retried, or rejected.
3. Make the workflow observable: add checks, artifacts, state, screenshots, tests, or structured outputs.
4. Preserve the method: docs, skills, scripts, project pages, changelogs, or blog posts.

This is the pattern behind most of my recent work: AI collaboration, Apple products, media runtime maintenance, browser validation, publishing pipelines, and project-memory extraction.

我做的不是「把 AI 接進產品」而已，而是把真實工作裡的模型推理、上下文管理、狀態轉移、失敗邊界、發布流程和產品維護，整理成可觀測、可重跑、可審查、可交付的系統。

我的公開資料分成三層：

• GitHub：實作、runtime、工具、plugin、發布與維護表面。
• RonnieCC：項目、文章、方法論與公開索引。
• Data / workspace：真實 repo、日誌、瀏覽器驗收、Notion material、Codex session 和本地產品現場。

我關心的是從真實材料裡提煉可重複的方法：讓 AI 協作不再停在 prompt，讓產品維護不只靠記憶，讓內容分發不是發出去就結束，讓每一次有效的判斷都能被固定成下次可用的系統。

• Website: ronniewong.cc
• GitHub: github.com/qoli
• Projects: ronniewong.cc/projects
• Blog: ronniewong.cc/blog