Die Passwortfrage im Regeltext

A site can be made visible ONLY WITH A PASSWORD, for anything not meant for everyone: lina4-publish <project> --lock. LOOK BEFORE YOU ASK: lina4-publish <project> --status answers at once, publishes nothing and triggers nothing (its one deliberate trace is the shared-ref it writes when it finds the current state proven). Is shared_ref filled and site_lock_pending false, this project has been published before, so the visibility was decided before you got here -- do NOT ask again. In every other case, and whenever no answer comes at all, ASK before the FIRST publish, in one plain question, and take the answer as it is -- whether something is meant for the whole world does not follow from what it is about. When they choose the password, --lock IS THE WHOLE COMMAND, also for a project that has never been published: it sets the protection up and puts the site online itself, in that order. Do NOT publish first and lock afterwards -- the site would stand open in between, and a page that was open for one second was open. NEVER say the password itself in the conversation and never write it into a file; the person reads it in the App. Open the skill "password" for everything else: where they read it, what to do when the lock did not go through, and why you never repeat a --lock blindly. and whether one is in place stands in site_locked, a field in every answer of lina4-publish; --status reads it at once and publishes nothing. NEVER say a password in the conversation. Setting one up or taking it off: the skill "password".

description: Making a project's site visible only to people who know a password, and taking that protection off again - when to ask about it, why the protection has to be set up before the first publish and never after, where the person reads their password, and why it is never said in a conversation.

when_to_use: Whenever who may see a site comes up, in any words, e.g. "not everyone should see this", "only for my club", "just for me and my family", "can I hide it behind a login", "put a password on it", "make it private", "it's not ready for the public yet", "take the password off", "what was my password again", "I forgot the password", "someone else should get in". And before the FIRST publish of a project, as one plain question - but look first whether this project has been published already, and then do not ask at all. Always on their word, never on your own: who may see the site is settled when the project is created, on the surface that creates it.

## Look first, ask only while the decision is still open

Whether something is meant for the whole world does not follow from what it is about. A club plan can be internal, a private cookbook can be public. So ask, in one plain question, and take the answer as it is.

But ask only BEFORE the first publish. Once a project has been out on the web, that moment is past and the answer was given without you: in the App the person chooses while the project is being created, and the site goes up that way. Asking again puts a decision in front of them that they have already made, over a site that is standing there either way.

You can see it. lina4-publish <project> --status answers at once, publishes nothing and triggers nothing, and two of its fields settle the question:

- shared_ref filled means something of this project has been out on the web (it is the ref refs/lina/shared in the project, written only against a proven publish). The first publish is behind them.
- site_lock_pending true means a password is set and its protection is NOT proven. That is not an answer, it is an open state.

So: shared_ref filled AND site_lock_pending false - do not ask. Everything else - an empty shared_ref, a waiting password, or no answer coming back at all - ask as above. A blank look is never a yes; read that way, a site nobody ever checked would quietly stand open.

## Act on their word, do not raise it yourself

Who may see the site is settled when the project is created, on the surface that creates it. So do not put that choice to them again, and do not read it off what the thing is about either: a club plan can be internal, a private cookbook can be public. When THEY bring it up, in any words, act at once and take what they say as it is.

- Password protection for a site: the skill "password". Ask about it BEFORE the first publish. You never raise it yourself; who may see the site is settled when the project is created.

Ask both of the following in ONE go, and put the password question into the same one if this is the project's first publish (the skill "password"). Never stack single questions in front of someone who has not seen anything of their own yet.