Portfolio packaging after review

A portfolio package is a curated story of a reviewed capstone for an external reader: the problem, role, core flow, selected evidence, decisions after feedback, and known limitations. It should be shorter than the repository and transparently show what is fact, what is an educational example, and what is Unknown.

After a review, there is no need to rewrite the story as if every recommendation had been completed. The package may contain a remediation backlog, open questions, and deferred claims. Packaging quality is determined by traceability and an honest evidence boundary, not by marketing confidence.

Portfolio package structure

  • One-line context: who the capstone is for and which bounded problem it addresses.
  • Role and contribution: what was designed or completed, marking unconfirmed details as Unknown.
  • Core flow: a short demo path with expected signals and a link to the submission package.
  • Evidence map: selected diff, checks, rubric, and mentor notes; every anchor has a boundary.
  • Review outcome: the actual decision or Unknown, without inventing approval.
  • Limitations and next step: remediation, deferred scope, and the next decision.

Portfolio package

PORTFOLIO_PACKAGE.md — documented example
# PORTFOLIO_PACKAGE.md
Title: <capstone name>
Problem and audience: <bounded context>
Role/contribution: <verified contribution or Unknown>
Core flow: <short observable scenario>
Selected evidence: <submission, demo, checks and review anchors>
Evaluation: <rubric summary or Unknown>
Review outcome: <observed decision or Unknown>
Limitations: <unsupported claims and open questions>
Next step: <remediation item or bounded follow-up>
Status: documented example; portfolio publication and external validation: Unknown.

Canonical lesson source · JavaRush

Open JavaRush material