Deeper writeups for the strongest proof points.

Problem

Agent-led development can move quickly, but it loses value when plans, approvals, status, and handoff evidence disappear into chat history. Relayframe turns that work into durable local execution state that can be inspected, resumed, reviewed, and mirrored into ClickUp without making ClickUp the source of truth.

Constraints

• The workflow has to support many project types instead of assuming every project is a web app.
• Local files must remain the durable source of truth while ClickUp stays a visibility mirror.
• External actions need clear policy boundaries so local work, pushes, deployments, and destructive operations do not blur together.

Approach

• Built a TypeScript CLI around intake, planning, ticket execution, status transitions, review evidence, and audit trails.
• Modeled project work as local artifacts so agent sessions can resume from durable state instead of memory alone.
• Separated orchestration policy from external actions so each approval boundary stays explicit and reviewable.

Architecture

• Node.js CLI commands drive project intake, next-action recommendations, sprint status, development loops, and workflow audits.
• Managed project folders store canonical tickets, execution state, evidence, approval packets, reviews, and handoffs.
• Visibility sync mirrors status, comments, schedules, assignees, and progress from local state into ClickUp.

Verification

• Workflow commands generate durable audit files for task status, development, review, and approval events.
• Sprint state records task transitions, verification results, and resumable return packets.
• Approval and review packets make external-action scope and evidence inspectable before release.

Outcomes

• Projects get a repeatable path from intent and intake through implementation, review, and release readiness.
• Agent sessions can continue from local state after interruptions or handoffs.
• Planning, implementation, verification, and shared visibility stay connected without relying on private chat context.

Problem

Long Minecraft VODs contain useful moments, but finding, scoring, rendering, reviewing, and preparing clips for upload becomes slow and inconsistent when every step is manual. The project organizes that pipeline around real media evidence and a dashboard built for review before publication.

Constraints

• Clip decisions must be grounded in the actual VOD, transcript, corrections, and rendered output.
• Review tools need to stay compact and operational instead of becoming a generic media dashboard.
• Uploads, OAuth data, channel details, and storage paths must remain protected until explicitly reviewed.

Approach

• Built the product direction around a Next.js dashboard, worker pipeline, and VOD-centered review workflow.
• Kept quality checks ahead of upload preparation so rendered clips can be inspected before publishing.
• Used local storage and database state as evidence for queue counts, review status, and clip readiness.

Architecture

• Dashboard routes expose ingestion, queue, review, and clip-management surfaces.
• Worker jobs handle VOD download, transcription, scoring, rendering, and upload preparation.
• Database records and storage files provide the shared state between the web app, worker, and review screens.

Verification

• Pipeline behavior is checked against real storage files and database rows, not only mocked UI state.
• Rendered clips remain review-gated before upload.
• Metadata and captions are tied back to transcript and correction data.

Outcomes

• The workflow reduces repeated manual review steps across VOD selection, clip scoring, and rendering.
• Reviewers can focus on the latest job and the actual rendered clip state.
• The public case study can describe the architecture without exposing private creator, OAuth, or workspace details.

Problem

Photo backup and cleanup workflows are risky when automation hides credentials, deletes before validation, or gives users no clear evidence of what will change. PhotoDrain and PhotoVault FreeUp are framed around local control, explicit review, and confirmation before cleanup.

Constraints

• The assistant must avoid storing Google account passwords or bypassing normal login expectations.
• Destructive cleanup should remain gated behind visible evidence and explicit confirmation.
• Screenshots and examples must not expose personal photos, account identifiers, or private library metadata.

Approach

• Designed the workflow around manual Google login, Takeout-based backup paths, local validation, and dedupe reporting.
• Kept automation focused on organizing evidence before cleanup rather than hiding decisions from the user.
• Documented destructive actions at a safe architectural level for the public portfolio.

Architecture

• Electron and React provide a local desktop surface for backup, validation, and cleanup review.
• Local state tracks imported evidence, duplicate candidates, and cleanup readiness.
• Confirmation gates separate analysis from deletion or space-freeing actions.

Verification

• Backup and cleanup states are designed around local evidence before user action.
• Deletion remains blocked until the user explicitly confirms the reviewed plan.
• Public materials are reviewed to avoid account names, personal images, and session details.

Outcomes

• The workflow positions photo cleanup as a reviewed local process instead of an opaque cloud automation.
• Users retain control over account login and destructive actions.
• The case study demonstrates practical safety boundaries for consumer data tooling.