Portfolio presentation

Truthful status, social-preview, diagram, and demo patterns.

1: Status treatments
2: Social previews
3: Diagrams and demos

Portfolio presentation must make maturity and limitations easier to see, not make prototypes appear more complete than they are.

Status treatments define the approved maturity vocabulary.
Social previews define reusable repository artwork.
Diagrams and demos define evidence and source requirements.

These patterns are Projectious organization assets. Bernhard Gerlach’s personal LinkedIn profile is a separate identity: use his name, portrait, and first-person voice only with his approval. Do not turn a personal profile into an organization-brand channel or imply personal endorsement.

1 - Status treatments

Text-first maturity labels for truthful portfolio presentation.

Required pattern

Every project presentation must show a status as text. Color, icons, position, and motion may reinforce the label but must never replace it.

Status	Use when	Supporting cue
Usable project	Documented users can complete the stated core task.	Solid dot
Working prototype	A real implementation runs, with known limits.	Half-filled dot
Applied research	Evidence or experiments are the primary output.	Diamond
Supporting asset	The repository enables another project.	Square
Idea / implementation starting	Scope exists; implementation is absent or partial.	Ring
Archived	Work is preserved but no longer maintained.	Horizontal bar

Do not substitute broad claims such as “platform”, “production-ready”, or “enterprise” unless the owning repository publishes evidence for that claim. Prefer narrow artifact categories: CLI, process layer, applied research, prototype, library, or supporting asset.

Accessibility

Keep the full status label visible at all viewport sizes.
Pair every color with the status-specific shape in the table.
Use normal text contrast of at least 4.5:1 and large-text/UI contrast of at least 3:1.
Test light and dark variants independently.
Do not encode a status change with animation alone.

The source templates use high-contrast neutral text and reserve accent color for a supporting rule. Maintainers must rerun local validation after changing colors.

Project examples

Examples are prompts for maintainers, not permanent factual claims. Confirm each status and limitation with the owning repository before publishing.

Project	Narrow category	Example status line	Required limitation
aibox	CLI	Usable project	State supported hosts and providers.
processkit	Process layer	Working prototype	State current API/version constraints.
ai-market-research	Applied research	Applied research	State dataset date and methodology limits.
KubeClaw	Prototype	Idea / implementation starting	State which flows are implemented.

2 - Social previews

Repository artwork that states category and maturity plainly.

Content model

Every 1280×640 preview contains only:

Projectious organization mark and name.
Project name.
One narrow artifact category.
One complete maturity label from the status vocabulary.
An optional short limitation, never a marketing claim.

The editable source is brand/portfolio/social-preview-template.svg. Replace bracketed text, keep the status label intact, and save a project-specific SVG beside the template. Examples for aibox, processkit, ai-market-research, and KubeClaw demonstrate the content structure; they are not evidence of current maturity.

Export and validation

Run:

npm run portfolio:validate
npm run portfolio:export

The export script uses resvg when available and otherwise leaves the SVG source as the canonical reusable asset. Commit generated PNGs only when a repository needs them.

Source and generated exports use this repository’s split license. The Projectious name and marks remain subject to TRADEMARK.md. Record any third-party typeface, icon, logo, or screenshot in brand/PROVENANCE.md before use. The supplied templates contain no third-party logos or screenshots.

3 - Diagrams and demos

Evidence-first architecture, flow, screenshot, and demo framing.

Architecture and flow diagrams

Prefer left-to-right flow, explicit boundaries, and named protocols.
Distinguish implemented components from planned components with text: implemented, external, or planned.
Add a caption with repository, source path, commit or release, and capture date.
Never infer architecture from a social preview or marketing page.
Keep editable source beside the export and document the export command.

Suggested caption:

Source: owner/repository, docs/architecture.svg, release vX.Y.Z, captured YYYY-MM-DD. Planned elements are labelled.

Screenshots and demos

Show real output from a named build, commit, or release.
Frame the output without modifying product state or hiding errors.
State sample/synthetic data clearly.
Do not fabricate dashboards, terminal output, customer logos, or product UI.
Crop personal data, tokens, account identifiers, and unrelated windows.
Record capture command, viewport, theme, and date in provenance.

When there is no real output yet, use a text-first project card labelled Idea / implementation starting. A truthful absence is better than a fictional interface.