Deeper writeups for the strongest proof points.

Problem

AI-assisted development can move quickly, but it loses value when plans, approvals, status, and handoff evidence disappear into chat history. Mark Project Builder turns that work into durable local artifacts 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 such as target edits, pushes, and deployments need explicit approval boundaries.

Approach

• Built a TypeScript CLI around intake, planning, sprint execution, status transitions, approval packets, and audit trails.
• Modeled project work as local artifacts so Codex sessions can resume from files instead of memory alone.
• Separated implementation, review, push, and deployment gates so risky actions are visible before they run.

Architecture

• Node.js CLI commands drive project creation, next-action recommendations, sprint status, dev-loop packets, and workflow audits.
• Project folders store intake, tickets, sprint execution state, approval packets, and review artifacts.
• ClickUp sync writes status, comments, schedule, and assignee visibility from local state.

Verification

• Workflow commands generate durable audit files for task status, dev-loop, review, and approval events.
• Sprint state records task transitions and local verification notes.
• Approval packets document target edit, push, and deploy boundaries before external actions proceed.

Outcomes

• Projects get a repeatable path from idea intake to sprint work and review packets.
• Codex sessions can continue work from local state after interruptions.
• The system keeps planning, implementation, verification, and visibility 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.