The last step is the one people skip, and it is the one that changes everything. A project nobody can open is a folder. A link you can send is a project.
Before you publish
Two hard gates.
No secrets. Search the whole repository one more time — keys, tokens, passwords, .env files that were never gitignored, personal paths, an email you would rather not publish. Check the history too, not just the current files: a secret committed and later deleted is still in the history and still exposed. If one got out, rotate it. Do not reason about whether anyone noticed.
It runs from a clean clone. Copy the repository to a fresh folder and start it from the README instructions, exactly as written. This is where you discover the file that only exists on your machine.
Check the ignore list against the folder
Level 1 taught you that a plain ls hides every name starting with a dot. That was about what the agent can see. This is the same fact with the stakes changed, because now the audience is everyone.
.gitignore is a claim: these paths stay private. Nobody ever goes back and checks whether the claim still covers the folder. Files arrive during a build session — from a hosting tool, from a setup step, from the agent following your instructions — and the ignore list does not grow with them.
Your turn. The project folder in the terminal below is one step away from its first push. Put the full contents of the folder next to what the ignore list actually covers, find the file that is in one and not the other, and read it before you decide what it is. Then close the gap.
Do this before the first push and it is a fix. Do it after and it is not: the file is in the history by then, and the only real repair is to rotate the credential and treat the old one as public.
The .env you forgot
This is the single most common way a beginner leaks a key. Confirm your .gitignore covers it, and confirm with git status that the file is not being tracked, before your first push and not after. (The simulated git here does not read .gitignore, so it keeps listing the file — on your own machine it does, and git status is where you verify rather than assume.)
Getting it online
Where depends on what you built — a static page, a small server, a script other people run themselves. The mechanics differ; the requirement does not: the person receiving the link should be able to use the thing without asking you anything.
Ask the agent for help with the specific route, and ask it to explain what each step does rather than just running them. A deployment you do not understand is one you cannot fix at the worst possible moment.
Quick check
What is the minimum a published project needs to include?
What you now owe it
Publishing is not the end of the relationship. The list is short and genuinely obligatory:
Keep it working. Links rot, services change, dependencies break. Open it every few months and check it still runs.
Take security updates. If your dependencies have a known vulnerability, that is now your problem, because your name is on the thing.
Be honest about status. If you have stopped maintaining it, say so in the README. Nobody minds an unmaintained project. People mind an unmaintained project that looks maintained.
Answer or do not promise. If you invite issues, read them. If you do not want to, say the project is provided as-is. Both are fine; silence after an invitation is not.
Retiring is allowed
“This was a learning project, it is no longer maintained, feel free to fork it” is a complete and respectable ending. Ending a project deliberately is a skill too, and a much better look than a dead link.
Whose project is it
You scoped it. You said no to the features that would have sunk it. You reviewed every change, caught the wrong ones, and decided when it was done. You are the one who will keep it running.
That is authorship. The typing was assisted; the judgement was not, and the judgement is the part that made it exist.
Be straightforward about the tools when it is relevant — in a team, in a portfolio, wherever it matters — and be equally straightforward that the decisions were yours. Both statements are true, and they are the same statement.
Where to go next
Build the second one. It will be better and it will take less time, because you now know the loop: scope small, one turn at a time, review everything, commit constantly, ship it.
That loop does not change with a bigger project. Only the number of turns does.