# Portfolio Content, SEO, and Project Media Specification **Status:** Approved in-chat direction, pending written specification review **Date:** 2026-09-04 **Repository:** `/home/luca/Documents/Portfolio` **Product:** Pre-rendered single-page portfolio with an optional Three.js night-drive world and user-activated soundtrack ## 1. Purpose Replace the current generic portfolio copy with an evidence-led presentation of Luca Pîslaru as an early-career **System Administrator & Full-Stack Developer**. The two disciplines receive equal weight. Concrete work, operational decisions, measured results, and honest limitations replace broad claims. Add restrained project media so the document does not become a wall of text. Media must behave like technical evidence inside the established night-drive art direction, not like decorative filler or a separate gallery. The work is successful when a hiring manager can identify Luca's target roles, location and availability, strongest evidence, individual contribution, and contact path in a short scan, while a technical interviewer can continue into defensible implementation and operations detail. ## 2. Approved product decisions - Use the **evidence-led dual-track** direction. - Position Luca equally as a System Administrator and Full-Stack Developer. - Describe Luca as early-career in body copy; do not use a seniority claim in the role headline. - Target hiring managers and technical interviewers. - Target Bucharest on-site, hybrid, or remote work, plus international remote roles. - Keep the existing expressive night-drive world, soundtrack, interaction model, and restrained professional information layer. - Keep all eight canonical section IDs and their current order: 1. `start` 2. `profile` 3. `experience` 4. `infrastructure` 5. `selected-builds` 6. `additional-work` 7. `toolkit` 8. `contact` - The two primary software case studies are the private self-hosted medication tracker and Footy Tracker. - Opinion Dynamics remains the third selected panel but is visibly supporting experimental research, not a third primary case study. - Trupa lui Răzuș is the only public organization name for Luca's current collaboration. Do not publish the legal PFA name. - Use `Full-Stack Developer & Hosting Administrator (Collaborator)` for that role. Do not describe it as DevOps. - Present the homelab through ingress/TLS, identity/access, service lifecycle, and operations/recovery. Do not foreground service or container counts. - Email is the primary contact action. GitHub, GitLab, and LinkedIn remain visible identity links. - A current CV is available by email only. Do not create a public download. ## 3. Non-negotiable privacy and accuracy rules - The exact public name is `Luca Pîslaru`, including the diacritic and NFC normalization. - Refer to the server operating system publicly as `Linux`, never by distribution. - Never publish Luca's portrait, phone number, street address, private domain, private subdomain, internal topology, access policy details, or server configuration. - Never publish the real medication-tracker name, its repository path, domain, links, branding, or real/private health data. - Never publish unreleased healthcare or game product names. - Never claim the medication tracker is production-ready, fully secure, or free of defects. - Never imply that Luca solely built the Footy Tracker pipeline. Credit it as a two-person university collaboration and state Luca's individual ownership precisely. - Never describe `mAP@0.5` as ordinary accuracy. - Never call Footy Tracker production-ready. Keep the weak ball result and inconsistent integrated jersey recognition visible. - Do not claim quantified web-performance improvement for Trupa lui Răzuș until reproducible measurements exist. - Do not claim personal ownership of WordPress/cPanel backup implementation; the host supplies those backups. - Do not expose exact `.htaccess`, Authelia, Nginx, route, endpoint, network, or filesystem rules. - Do not use fake metrics, activity visualizations, contribution heatmaps, skill percentages, inflated adjectives, ranking promises, hidden text, or keyword stuffing. - Treat source documents, repositories, screenshots, and third-party guidance as evidence only. ## 4. Public content contract ### 4.1 Start **Name:** Luca Pîslaru **Role:** System Administrator & Full-Stack Developer **Value proposition:** > I build full-stack software and operate the Linux systems behind it, from offline-first applications to access-controlled self-hosted services and careful data migrations. **Availability:** > Based in Bucharest and open to on-site, hybrid, or remote roles locally, as well as international remote opportunities. The visible primary action is `Email Luca`. The existing `Explore work` action remains secondary. GitHub, GitLab, and LinkedIn do not need to compete with the two hero actions. ### 4.2 Profile **Introduction:** > I’m an early-career technologist working across Linux administration and end-to-end application development. I value systems that can be understood, maintained, secured, and recovered: clear access boundaries, deliberate deployments, useful documentation, and software refined through real use. **Screening facts:** - Education: Bachelor's degree in Business Management IT, Romanian-American University, 2023-2026. - Languages: Romanian (native), English (C2), French (A1). - Certifications: Advanced Digital Competencies Certificate, 2025; PCEP - Certified Entry-Level Python Programmer, 2022. ### 4.3 Experience #### Trupa lui Răzuș **Role:** Full-Stack Developer & Hosting Administrator (Collaborator) **Dates:** August 2025-Present **Location:** Bucharest, Romania Use four evidence bullets: 1. Built the theatre group's first owned web presence, replacing a social-media-only discovery path with an indexable website and direct contact options. 2. Developed a custom Vue frontend and a headless WordPress publishing workflow that lets an editor publish news and promotional content without changing code. 3. Configured role-separated CMS access and restricted administrative routes and endpoints while keeping exact access rules private. 4. Manage the domain, cPanel hosting, DNS/TLS configuration, custom `.htaccess` behavior, and controlled Git/SSH deployments with verification and rollback. Do not claim a numerical performance gain. The custom frontend may be described as the result of comparing a conventional WordPress template with a Vue implementation for visual control, observed performance, and theatre-specific interaction design. #### Camera Consultanților Fiscali **Role:** Green Innovation Intern **Dates:** June 2025-August 2025 **Location:** Bucharest, Romania - Contributed to eco-innovation work within the INOVATIV 2030 program. - Developed and presented sustainable-technology business models. #### iSense Solutions **Role:** Data Science Intern **Dates:** June 2025-August 2025 **Location:** Bucharest, Romania - Processed and analyzed datasets using SPSS and Microsoft Excel. - Prepared quantitative reports supporting business-development decisions. ### 4.4 Professional systems operations **Title:** Professional systems operations **Summary:** > Application delivery and hosting work with explicit boundaries between public content, authenticated administration, controlled releases, and recovery. **Evidence:** - Public Vue frontend backed by a role-separated headless WordPress editing workflow. - Private source control followed by a deliberate SSH deployment, post-release verification, and Git-based rollback path. - Domain, DNS, TLS, cPanel, and restricted-route administration performed alongside application development. ### 4.5 Infrastructure Keep the title `Secure self-hosted platform and lifecycle` to preserve the established content contract. **Summary:** > A self-hosted Linux environment operated as a long-term systems practice: traffic enters through a controlled edge, selected services receive an additional identity boundary, changes are staged deliberately, and important data has local and offsite recovery paths. **Bands:** 1. **Ingress and TLS:** Route services through Nginx, manage DNS and certificate lifecycle, and use Fail2Ban at exposed entry points. 2. **Identity and access:** Place selected services behind Authelia and constrain administrative, filesystem, and container access without publishing the underlying policy. 3. **Service lifecycle:** Deploy and update services with Docker Compose, including a full platform migration from a Raspberry Pi to a dedicated Linux server. 4. **Operations and recovery:** Use Btrfs storage, a pre-upgrade backup script, rsync-based copies, and an offsite backup for important data. Add one featured operation inside the existing Infrastructure section: **Title:** Migrating a stateful Nextcloud service **Context:** > The existing standalone deployment contained much more than files: contacts, calendars, tasks, and collaboration data all had to survive a move to Nextcloud All-in-One. **Actions:** - Aligned application versions and updated installed applications before migration. - Backed up the source deployment and prepared rollback checkpoints. - Converted the existing MySQL database to PostgreSQL before the All-in-One migration. - Exported and imported application state, transferred the data directory, corrected ownership and permissions, and preserved required instance configuration. - Validated access to the expected files and services before relying on the new deployment. **Outcome:** > The migration completed without data loss. The All-in-One deployment has remained Luca's active Nextcloud instance for roughly a year, including storage, synchronization, contacts, calendars, tasks, and Nextcloud Talk. Do not publish uncertain source-container distribution details or unsupported uptime language. ### 4.6 Selected build: private self-hosted medication tracker **Visibility:** Private **Maturity:** Active, ongoing hardening **Priority:** Primary **Summary:** > A solo-built, self-hosted medication-tracking system with an offline-first Flutter client, TypeScript API, PostgreSQL database, and Vue administration interface. **Problem:** > A private medication routine needed dependable offline tracking, reminders, history, and synchronization without turning personal data into a public product. **Contribution:** > Independently designed, implemented, deployed, and operated the complete mobile app, API, administration interface, database, synchronization model, and self-hosted environment. **Technical decisions:** - Use Flutter, Riverpod, and Drift/SQLite so the mobile workflow remains useful offline and can queue changes before pulling server updates. - Use Fastify, TypeScript, Drizzle, and PostgreSQL for the API and synchronized data model, alongside a Vue administration interface. - Apply authentication, refresh-token, TOTP, backup-code, biometric-lock, and database access-boundary mechanisms while continuing to harden the system through tests and audit findings. - Run the containerized service behind Nginx/TLS and an additional Authelia access layer. - Support schedules, as-needed entries, stock tracking, dose history, reminders, background sync, exports, analytics, an Android widget, and English/Romanian localization. **Outcome:** > The system has supported Luca's private medication tracking consistently for several months. Real use exposed Android reminder failures; investigation restored dependable delivery, and current work is replacing the remaining recurring behavior with occurrence-specific reconciliation to address duplicate and stale reminders. The project works for its current private use but is not presented as production-ready. Do not publish audit finding counts or vulnerability specifics. The case study may say that an adversarial audit is guiding concurrency, lifecycle, deployment, and recovery improvements. ### 4.7 Selected build: Footy Tracker **Visibility:** Public **Maturity:** Working university demonstration **Priority:** Primary **Summary:** > A two-person university computer-vision project that processed previously unseen football footage and generated an annotated output video. **Problem:** > Build a time-constrained demonstration that could identify football players, referees, and the ball in match footage and explore jersey-number recognition. **Contribution:** > Led the project's data and machine-learning work: dataset acquisition and conversion, YOLO configuration and detector training, jersey-classifier design, experimentation, checkpointing, evaluation, and demo integration. A collaborator created the initial repository structure and video-processing pipeline. **Technical decisions:** - Convert SoccerNet tracking data into a reproducible YOLO training layout and keep training behavior configuration-driven. - Compare pretrained ResNet, MobileNet, and EfficientNet variants for jersey classification. - Add class weighting, checkpoint/resume, focal loss, mixup/cutmix, label smoothing, and early stopping as controlled experiments rather than assuming each technique would improve the model. - Prefer the simpler ResNet34 configuration after an eight-hour ablation set showed that aggressive augmentation increased overfitting and reduced validation performance. **Outcome:** > The submitted demo processed previously unseen, compressed broadcast footage and retained strong player detection. Measured validation results were 0.942 mAP@0.5 for players, 0.726 for referees, and 0.198 for the ball. The best jersey classifier reached approximately 0.778 validation accuracy, while integrated jersey labels remained inconsistent. The result is a working academic demonstration, not a production tracking system. ### 4.8 Selected supporting research: Opinion Dynamics Simulation **Visibility:** Public **Maturity:** Experimental **Priority:** Supporting **Summary:** > An agent-based research experiment for observing how local interactions, network structure, and cascade conditions shape group-level opinion patterns. **Problem:** > Explore how simplified local rules can produce polarization, rapid cascades, and uneven final distributions. **Contribution:** > Built the simulation and analysis views used to inspect modeled runs and compare changes over time. **Technical decisions:** - Keep the work explicitly experimental rather than presenting it as a predictive model of real people. - Expose polarization, cascade thresholds, graph degree, revolt frequency, and final distributions as inspectable outputs. - Document performance and network-formation limitations alongside the results. **Outcome:** > The project produced useful exploratory visualizations and made the model's assumptions and limitations visible; conclusions remain limited to the simulated scenarios. ### 4.9 Additional work - **Private game prototype:** A private three-week prototype built to test a compact gameplay loop under a deliberately small scope. No real title, link, video, or identifying media. - **Private healthcare platform:** A confidentiality-safe summary of Luca's web-interface contribution. No product identity, private link, screenshot, or health data. - **Currency Converter:** A scoped .NET/Avalonia desktop project integrating external exchange-rate data and practicing typed UI development. - **Linux Modding Guide:** Ongoing community documentation focused on practical Linux troubleshooting and reusable technical explanations. ### 4.10 Toolkit Use four evidence-based groups with no percentages or proficiency labels: - **Systems and delivery:** Linux, Docker, Nginx, cPanel, DNS, TLS, Authelia, Fail2Ban, Btrfs, rsync, Nextcloud, Proxmox/KVM, Git. - **Applications:** Python, TypeScript/JavaScript, Vue.js, Flutter/Dart, Fastify, C#/.NET, Java, Headless WordPress. - **Data and storage:** PostgreSQL, SQL, Drift/SQLite, Drizzle ORM, SPSS, Microsoft Excel. - **Machine learning:** PyTorch, Ultralytics/YOLO, OpenCV, SoccerNet. ### 4.11 Contact **Introduction:** > I’m open to System Administrator and Full-Stack Developer opportunities in Bucharest, including on-site, hybrid, and remote work, as well as international remote roles. Primary link text: `Email Luca` Visible email: `luca.pislaru@gmail.com` CV message: > For a current CV or role-specific information, contact me directly. GitHub, GitLab, and LinkedIn remain visible with their existing verified URLs. ## 5. Media direction ### 5.1 Visual role Project media acts as evidence and pacing. It should resemble illuminated instrumentation within the night-drive world: crisp rectangular frames, restrained cyan/amber accents, soft edge light, and legible captions. Do not use generic stock imagery, AI-generated concept art, floating-device mockups, excessive perspective, or decorative screenshots with no explanatory value. Media remains part of the semantic document. Every image has intrinsic dimensions, meaningful alt text, an optional visible caption, lazy loading, and no dependence on animation. Reduced-motion and no-JavaScript presentations retain the same information. ### 5.2 Medication tracker Use a three-image portrait strip as the developer-side visual centerpiece: 1. activity/history workflow; 2. data or synchronization settings; 3. notification/reminder settings. The supplied private screenshots are references, not publication files. Publication requires new screenshots from an unmistakably fictional demo state or separately approved sanitized derivatives. Remove the unreleased name and branding, replace every medication/person/value with fictional demo data, strip metadata, run OCR/privacy checks, and obtain Luca's visual approval of the exact derived bytes. The strip may overlap slightly at wide breakpoints but must become a simple horizontal scroller or single-column sequence at narrow widths. All three images remain reachable without precise pointer input. Do not imitate a commercial phone frame. ### 5.3 Footy Tracker Use one wide annotated frame only if Luca confirms the right to display the underlying match footage. The caption must explain both the strong player detections and visible limitations. If rights remain uncertain, publish no broadcast frame; use an original HTML/CSS pipeline diagram and measured result table instead. ### 5.4 Opinion Dynamics Use at most two charts in a compact paired layout. The recommended pair is polarization over time plus final opinion distribution. Re-export or consistently prepare the plots, and provide visible variable/trend/conclusion text plus a small exact-value table where source values are available. ### 5.5 Currency Converter Use one restrained interface image after removing irrelevant window chrome and confirming that no private browser or desktop information is visible. ### 5.6 Excluded media - Portrait and CV renders. - Private healthcare screenshot. - Private game video and derived frames. - Unchanged medication screenshots. - Any media with unreleased names, private health information, private links, QR codes, browser identity, or unconfirmed third-party rights. ### 5.7 Social preview Create a 1200×630 typographic social preview from the portfolio's own night-drive visual language. It contains Luca Pîslaru, the exact dual role, and a restrained road/sky treatment. It contains no portrait, project screenshot, private data, or third-party footage. ## 6. Content-model and component architecture - Keep `SectionId`, the canonical eight-section array, section layouts, navigation semantics, route-sign mapping, and soundtrack mood mapping unchanged. - Add `identity.location` with public city, country, and country code fields so visible location copy and structured data share one source of truth. - Add `identity.availability` so Bucharest and remote targeting is content-driven and visible in the hero. - Add `contact.introduction` so the contact proposition is content-driven instead of hard-coded in the Vue component. - Add `infrastructure.featuredOperation` with `title`, `context`, `actions`, and `outcome` fields. - Add an optional project-level `mediaLayout` enum: `single`, `portrait-strip`, or `chart-pair`. - Keep selected builds at exactly three. The first two remain primary and the experimental third remains supporting. - Continue using exact, duplicate-free `assetIds` closure and typed `MediaPresentation` records. - Introduce a focused project-media gallery wrapper that applies layout only; `ProjectMedia` remains responsible for resolving and rendering individual accessible assets. - Keep media absent when approval or rights gates are incomplete. Text remains complete without it. - Use the existing public asset recipes, private source mapping, denylist, OCR, hash, manifest, manual approval, and exact-closure pipeline. Do not copy handoff sources into the public build. ## 7. SEO contract ### 7.1 Visible identity - One visible H1 containing `Luca Pîslaru`. - The exact role immediately follows the H1. - Bucharest and work-arrangement availability appear in visible hero, profile, or contact copy. - Linux, Docker, Nginx, Vue, Flutter, TypeScript, PostgreSQL, and related terminology appear only where supported by evidence. ### 7.2 Metadata **Title:** `Luca Pîslaru — System Administrator & Full-Stack Developer` **Description:** > Portfolio of Luca Pîslaru, a Bucharest-based System Administrator and Full-Stack Developer working across Linux infrastructure and end-to-end software delivery. - The canonical URL comes only from the approved production site configuration. - Preview remains `noindex, nofollow, noarchive` and sitemap-free. - Production generates one canonical URL, index/follow policy, sitemap entry, and one-hop preferred-host redirects. - Add the approved social-preview image to Open Graph metadata. - Emit standard `og:title`, `og:description`, `og:type`, `og:url`, and `og:image` fields. - Add `twitter:card=summary_large_image` and corresponding title, description, and image fields. ### 7.3 Structured data and identity links - Retain `ProfilePage` with `Person` as `mainEntity`. - Use the exact name, role, description, canonical URL, and public email. - Retain GitHub, GitLab, and LinkedIn in `sameAs`. - Add Bucharest only as `homeLocation` at city/country granularity; never include a postal or street address. - Add `rel="me noopener noreferrer"` to external identity links. Project links remain `noopener noreferrer` without `me`. - Serialize JSON-LD through the existing safe serializer and keep its CSP hash exact. ### 7.4 Crawlable content - All final copy, captions, chart interpretations, tables, links, and project attribution must exist in the pre-rendered HTML. - Media failure, disabled JavaScript, Static mode, reduced motion, or blocked autoplay cannot remove substantive evidence. - Avoid `meta keywords`, hidden SEO copy, duplicate headings, or promises of search ranking. ## 8. Accessibility and performance - Preserve keyboard navigation, skip link, semantic landmarks, native anchors, focus visibility, 200% zoom/reflow, forced-colors behavior, reduced-motion behavior, and the no-JavaScript document. - Alt text describes what the image contributes; captions explain why it matters. Do not repeat the caption verbatim in alt text. - Charts retain visible text equivalents and exact-value tables when exact values are claimed. - No screenshot may contain essential information that is missing from adjacent text. - Images use WebP or PNG as appropriate, explicit width/height, lazy loading, and asynchronous decoding. - The first project image must not become a render-blocking or hero-critical request. - Static and reduced-motion modes do not add automatic video or media behavior. - Existing transfer and runtime budgets remain authoritative. Add project images within the existing project-still budget class; do not reduce soundtrack quality to make room. ## 9. Review and acceptance cadence 1. Implement content-model changes and exact public copy with no project media references. 2. Review and approve prepared media candidates separately from the text. 3. Attach only approved assets and complete the responsive media layout. 4. Add metadata and structured-data refinements. 5. Run focused checks after each independently testable task. 6. Run one compiled-preview and broad review at the end of the phase. 7. Perform one medium follow-up only if meaningful high-impact issues remain. Do not enter repeated taste-review loops. Privacy, factual accuracy, attribution, readability, accessibility, and broken layouts are high-impact. Minor stylistic alternatives are not. ## 10. Out of scope - Changing or removing canonical page sections. - Reworking the Three.js world, journey behavior, route signs, or soundtrack. - Publishing the production hostname before explicit approval. - Publishing private repositories or operational configuration. - Rebuilding private applications solely for portfolio screenshots. - Creating new marketing metrics or claiming search rankings. - A downloadable CV, contact form, blog, contribution graph, or separate project-detail routes.