Răzvan Todică Business Portfolio & Automation OS

What this project is

This is a live personal portfolio, but it is deliberately more than a collection of pages. It is a private-first business operating layer for presenting engineering work, explaining product thinking, capturing qualified enquiries, managing editorial content, and distributing approved stories across the channels where the brand already exists.

The public site is the visible layer: it explains the work, services, experience, and active projects in a business-first way. The protected owner workspace is the control layer: it manages leads, editorial drafts, source material, approvals, integrations, delivery status, and operational follow-up. The goal is to make the system useful both as a portfolio and as a repeatable engine for trust, conversations, and future content.

What it brings to the business

• A clearer public explanation of what is being built, why it matters, and what could come next.
• A controlled way to turn private GitHub projects into sanitized public case studies without making the repositories public.
• A single place to capture, review, qualify, and follow up on inbound opportunities.
• A source-backed editorial workflow that can create drafts and distribution variants while keeping human approval in the loop.
• A foundation for future video and social automation without pretending that an unverified provider integration is already production-ready.

Main capabilities

Public portfolio and project intelligence

The site contains the personal brand homepage, service pages, client/product work, contact flow, legal pages, and a live Currently Building area. The public project pages can show the business concept, current status, focus areas, roadmap, technology choices, selected links, recent activity, and a contribution-style graph.

Private GitHub repositories are never called directly by public visitors. The owner connects a read-only GitHub App, selects the repositories that are allowed into the portfolio, and adds an explicit .portfolio/allow file to each repository. The sync reads only the known public brief files and bounded GitHub metadata, sanitizes Markdown and URLs, and stores the public-safe result in Supabase. Removing the marker removes the cached project at the next successful sync.

The .portfolio contract keeps the project story next to the code:

• config.json holds title, status, technology, links, focus areas, display settings, and roadmap items;
• summary.md explains the idea, business value, current state, and future direction;
• implementation-plan.md contains the intentionally published milestone view for this repository;
• allow is the explicit publication switch.

Owner workspace, database, and security

Supabase provides the Postgres and Storage foundation. RLS policies keep owner data and editorial records behind the server-side boundary, while Supabase Auth protects the admin workspace. The service-side key is never sent to the browser. The architecture keeps public reads narrow and uses server routes for sensitive mutations.

Lead capture, mailing, and OpportunityOS

The contact form collects a structured enquiry with validation, consent handling, optional phone contact, attribution context, and abuse protection. A valid submission can be persisted as lead data and delivered through Resend as an owner notification plus a sender acknowledgement when the mail configuration is available. The owner can review leads in the private inbox, track their status, and open a direct reply flow without exposing the message to analytics.

The OpportunityOS integration is a protected, signed lead-delivery path. It can forward validated lead payloads to the external system when configured, records delivery attempts, and keeps failures visible for retry. It is not a public write endpoint and does not silently send unrelated visitor messages.

Chat and owner response

The homepage includes a session-scoped live chat launcher. Visitors can leave a bounded message and continue the same conversation during their session. The owner can set availability, read and answer messages from /admin/chat, and optionally receive Web Push notifications through the installed PWA. Chat data remains behind server routes and RLS-protected tables; it is not exposed as an anonymous Supabase browser channel.

The current chat is intentionally owner-replied. Automatic AI replies are not claimed as delivered; the next step is to decide whether an AI assistant should draft replies under the same owner review and privacy rules.

AI-assisted editorial automation

The editorial pipeline uses a curated source registry instead of unrestricted scraping. It normalizes and deduplicates source items, ranks relevant material, creates an article brief and original draft, produces one shared short social variant, and prepares a vertical-video brief. When the server-side OpenAI configuration is available, it can also generate a structured editorial package and an optional cover image. Provider failures fall back to a deterministic source-backed draft and leave the cover ready for explicit review rather than making a false claim.

The owner can edit, approve, schedule, publish, retry, or reject. Automatic publishing is gated by an explicit owner policy, a complete package, a source trail, and idempotent delivery records. The system keeps a run ID, step status, error state, retry path, and audit trail so an automation failure does not become an invisible business failure.

Social and content distribution

The distribution workspace reuses one approved short post and its approved cover rather than asking the AI to invent a separate story for every network. The current connector surface includes:

• LinkedIn personal profile publishing;
• Facebook Page publishing and a separately audited Page Story follow-up;
• X publishing, including mechanical thread splitting when needed;
• Instagram professional feed publishing with a native Share to Story handoff;
• Threads and Bluesky publishing;
• Pinterest Business and Personal connector paths with separate account authorization and Board selection.

Every delivery is approval-gated, provider-specific, retryable, and protected against duplicate publishing. Pinterest Business still has external developer setup/approval follow-up, and Pinterest Personal requires its separate owner authorization. YouTube Shorts and TikTok currently receive reviewable briefs and manual posting support, not claimed automatic video publishing.

What is still coming soon

The next product step is an end-to-end video pipeline:

1. take an approved article or live-post concept;
2. generate a vertical video with a controlled visual language, voice/captions, and safe asset provenance;
3. keep the video as a reviewable asset in the private workspace;
4. publish only after owner approval to Instagram Reels, Facebook Reels, TikTok, and YouTube Shorts;
5. record a provider-specific delivery result, permalink, retry state, and duplicate guard.

This is intentionally marked Coming soon. The repository already produces editorial video briefs, but automatic video generation and automatic Reels/Shorts/TikTok publishing are not yet implemented as a complete production flow.

Current activity

The portfolio sync can show the last 365 days of repository activity, including commits, pull requests, issues, and reviews. This project also exposes a public GitHub profile card for ToDy95. The profile card uses public GitHub statistics and, when selected portfolio repositories are synchronized, a privacy-safe aggregate of their activity. Private repository details and the owner's global private GitHub contribution total are not copied into the public portfolio.

Guardrails

The project is designed around private-by-default integrations, explicit opt-in, server-only secrets, RLS, consent-aware analytics, source attribution, human review before external publishing, idempotent retries, and honest status labels. It is a portfolio, but it is also a small operating system for turning engineering work into evidence, conversations, and durable business assets.