MOJ: Organizer manual (the contest .admin panel)

Translation note. This manual is a translation of the Portuguese original. The command-line tools (moj, moj-contest, moj-comp) print their messages in Portuguese, and the command examples below are identical to the original.

This manual is for the person who operates a contest: the owner of the .admin account. It explains each tab of the administration panel and each configuration option. It also explains how to enable the special roles (.judge, .cjudge, .staff, .cstaff, .mon) and how to turn on judge-validated grading, including how many persons you need.

Creating the contest (wizard, problems, accounts) is in the other guide: the organizer tutorial. This manual is about OPERATION, on the contest day.

To get to the panel, log in with the .admin account of the contest. Then click Administration in the top bar.

1. The panel: Home, the groups and the MODULES

The panel opens on 🏁 Home. The top bar has the four common groups, which every contest has. After a separator, it has the event groups. An event group appears only when the contest turns on the related module (section 1½). Each group shows its panels on the second line. The address keeps the panel (#group/panel), so you can save the link. The old links (#settings, #users, #machines, #prova/rodadas…) continue to work: they are redirected. A link to a panel of a module that is off goes to Home › Modules, with a notice that tells which module to turn on.

[🏁 Home] [🧩 Contest] [👥 People] [🎛️ Operations] │ [🏟️ Event] [🖥️ Machines]        📖 Manual
                                                   └── only with the module on ──┘

🏁 Home: what is missing and what to generate

🧩 Contest: the content

🌐 Statement languages. A problem from the bank can have its statement in Portuguese, English and Spanish (the author writes docs/enunciado.en.md and docs/enunciado.es.md in the package). The 🌐 Statement languages panel (Contest › Problems; the chief judge has the same panel in the 🌐 Languages tab of the chief judge panel) has two modes:

• Automatic (the default, with no configuration): each problem offers in the accordion all the languages that it has. A problem only in Portuguese shows no chips.
• Only these languages: select the list. Only PT selected = contest only in Portuguese, even if a problem has a translation.
• The accordion opens in the contest language (LOCALE) if the contest offers it. If not, it opens in the first language. The competitor changes the language with the PT · EN · ES chips, and MOJ remembers the choice.
• If the contest offers a language and a problem has no translation for it, that problem shows the Portuguese text. The table of the panel shows, per letter, what exists.
• To send your own HTML or PDF for a language, select the language in the selector next to the Send HTML / Send PDF buttons. The file applies only to that language.
• The problem set and the editorial in EN/ES use the translation of each problem. A problem without a translation is in Portuguese in the problem set. The problem title is also translated.

Problem name in the contest. The name in the problem list, in the clarifications, in the submissions and in the report is ONE name per problem. When you insert a problem and do not type a name, MOJ uses the bank title in the language that the accordion opens (the LOCALE, if the contest offers it). If the problem has no title in that language, MOJ uses the Portuguese title.

• When the problem has a title in more than one language, the bank search shows the titles (🌐) and the name field shows the PT · EN · ES buttons. Click a button to use the title in that language. This applies in the creation wizard, in Rename (Contest › Problems) and in Round problems.
• In the wizard, an empty name is automatic: the Review step shows the title that MOJ will use with the language from step 5.
• The Central shows a warning (Problem name in a language other than the contest's) when the name is the bank title in another language and a title in the contest language exists. This occurs in a contest created before this rule, or in a contest that changed its language after the problems were inserted. The 🌐 Use the titles in the contest language button changes only these names. A custom name does not change. If you want the name in another language, save it in Rename and the warning goes away.
• In the CLI: moj-contest -c <cid> problems titles shows the titles of each problem, and problems apply-titles does the same as the Central button.

👥 People: who gets in, who is who

🎛️ Operations: the contest day

🏟️ Event: what a multi-site contest has in addition

🖥️ Machines: when the contest runs on Maratona Linux (module maquinas)

Balloons and the freeze. By default, an accepted submission made while the scoreboard is frozen does not create a balloon task. These balloons are not delivered later: the task does not exist. This is the competition rule (a balloon that moves through the room shows what the freeze hides). It applies only to balloons: print requests continue to work. If you want the classic ICPC behavior (balloons in the room during the freeze, and the audience guesses), check Deliver balloons during the freeze in Home › Rules. This also releases the balloons that were already held. The pre-contest checklist shows which policy applies, and Operations › Status shows how many balloons are held.

How the scoreboard marks who solved a problem. By default, the cell of a team that solved a problem is always the same (green), and the balloon color is in a dot next to it. This is intentional. The ICPC palette gives problem A the color white, and white on the white background of the scoreboard is the same pixel. A team that solved A looked like it did not solve it (the complaint that caused the change came from a student). If you prefer the classic style (the full cell painted with the balloon color), set it in Home › Rules › "Solved" cell on the scoreboard. Light colors get an outline so that they stay visible. This applies to the scoreboard, the reveal ceremony and the report.

Outside the panel, but linked from Home: credential badges, reveal ceremony, jplag, staff queue and scoreboard.

1½. Contest modules: turn on only what your contest uses

A module is a group of features that the contest uses. A course exam turns on no module: the panel shows only the common part (problems, accounts, sessions, scoreboard, staff, judges). A course exam in a lab with Maratona Linux turns on maquinas (machine gate, single session, anomalies). The Maratona turns on all of them. When you turn on a module, MOJ shows the related panels, Home checks and cards. When you turn it off, MOJ hides them and deletes nothing. When you turn it on again, all comes back.

While a module is off, its rule does NOT apply, also with the configuration saved: Machines turns off the browser gate, the single session and the site lock (the pinned IPs are released at once); Sites turns off the per-site extension; Registration lets in persons who did not register (a team member still enters as the team), removes the Register button from the home page and nobody can register; Cohorts puts all teams on the public scoreboard; Balloons stops creating balloon tasks (turning it on again creates the missing ones). Before you turn off a module of a contest that is running, make sure that this is what you want.

Where to turn a module on: Home › Modules (the presets only preselect), step 7 · Modules of create contest, moj-contest -c <cid> modules on|off or the modules{} section of the creation spec. It also turns on automatically when you use the feature. Create a round or a cohort, turn on the gate, generate a document, turn on registration, set a balloon color, a site or a webcast key, on the web or in the CLI: the related module turns on immediately (the audit records modules-auto). Only turning off is manual. This also applies to the creation spec: one JSON creates the full contest, with the data of each module (sites, colors, cohorts, gate, rounds, documents, registration window, big screen, qualification). The export gives back the same section, without secrets. For contests created before the modules, MOJ detects the modules one time from the files that they already have (server/bin/contest-modules-detect.sh).

Prerequisites. Two modules only work with another contest setting, so they only turn on with it (virtual participation has its own conditions, in §6¾; the cheat sheet below shows all of them): inscricoes (registration) needs the Free Training accounts (a contest created with shared users): each student registers with their own training account. In a contest with its own accounts, registration would block every student, so it does not turn on (not from the panel, not when saving the registration window, not at creation, when duplicating or from a template). With own accounts, hand out the credentials in People › Accounts. esqueletos (code skeletons) needs the in-browser code editor (Rules). The module card shows a lock and what is missing. If a contest already had the module on without the prerequisite, the Home checklist warns (and, without the training accounts, the "registered only" rule does not apply). Converting shared accounts into own accounts (section 8¾) turns registration off as well.

Cheat sheet: what each module needs. On the left, what MOJ requires to turn the module on (↔︎ = it applies in both directions); on the right, what the module needs, when it is on, to do something.

Code skeletons (module esqueletos)

In a contest, the team code editor opens empty: the team writes its full code. With the module esqueletos, the editor opens with the language skeleton (the main and the usual reads). Use it in a course list or a course exam, when the skeleton helps the student.

• It needs the in-browser code editor on (Home › Rules). MOJ refuses to turn the module on with the editor off. MOJ also refuses to turn the editor off while the module is on: turn the module off first.
• In Contest › Skeletons, each language has three choices:
  • MOJ default: the same skeleton as in training;
  • custom: the skeleton that you write for this contest;
  • no skeleton: that language opens empty.
• When the team changes the language, the text changes only while it is still the untouched skeleton. The code that the team typed stays.
• The screen refuses to submit the skeleton without changes ("You have not changed the skeleton yet"). The empty-editor check still applies.
• A function-submission problem (the package declares FUNCTION_LANGS) opens empty in the driver languages: the main of the skeleton would give a Compilation Error.
• Warning: the editor sends the file as solution.<extension>. In Java, do not declare the class as public (javac requires a public class to have the file name). The Home page warns.
• The module is not in the "Maratona / ICPC" preset: in a programming marathon the team expects an empty editor. In an ICPC contest the Home page warns.
• The custom skeleton goes with the export, the template and the duplicate. From the CLI: moj-contest -c <cid> esqueletos ls|show|set|off|reset.

2. Rules (Home › Rules): option by option

Identity and window

• Name: the displayed title. The id (which becomes the subdomain) does not change.
• Start / End: the contest window. Before the start: a countdown. After the end: nobody can submit (except judge roles). For a fine-grained extension, use the ⏱ section (by login regex, for example only one room that lost power).
• Login opening (waiting screen): the time from which the student can LOG IN (before it, the login screen shows a countdown). Use it to open the login some minutes before the start. The API also blocks teams before this time (the organization can always log in). Changing the round does not change this field: with a warm-up and an official contest, set the opening before the start of the warm-up. The 🏁 Central warns when the opening is after the start (warning) or after the end (critical) of the round on the air. To remove the opening, clear the field and save: the login then opens at the start of the round.
• Scoreboard freeze: freezes the public scoreboard from this time (ICPC style). Judges and the admin continue to see all. The reveal occurs in the ceremony. Before the freeze starts, you can change or clear the field freely. After it starts, the scoreboard unfreezes only from the end of the contest for all sites + 1 minute.
• Language: Automatic (each person sees the screens in the language of their browser; it is the default of a contest with no saved language), Portuguese, English or Spanish. A selected language sets the screen language of all persons in the contest (with no selector). It also sets the language of the printed paper (print cover sheet and balloon sheet), of the final report and of the invitation messages on Telegram (in English or Spanish, the message also includes the Portuguese text). The statements and documents have their own language (🌐 Statement languages, Event › Documents).

👁 What the team sees during the contest

• Login enabled: turn it off to lock the door (the persons that are already in stay in).
• User can see the judging log: the test-by-test report. ⚠ In a graded contest, a visible log can leak the tests (the student sees the input/output). This is the classic "SHOWLOG". Turn it off.
• In-browser code editor available: the editor side by side with the statement.
• Show problems' time limit to users: shows the TLs per language in the statement.
• Allow file backup by users / Allow print requests by users (.staff): enable the backup upload by the student and the print requests (which go to the staff queue).
• Anonymous scoreboard: hides the individual performance: a person who is not in the organization gets from MOJ only the summary (how many solved how many problems, solvers per problem, quartiles), with no name and no score of any team. The organization (admin, chief judge, judges, .mon, .animeitor) sees the full scoreboard. While it is on, you cannot publish the report, the archived round site stays closed, the qualification does not show and virtual participation does not open.
• Login gate by UA substring: only browsers whose identification contains the substring can log in (locked contest machine). Privileged roles are exempt.
• 🕵️ SUPER SECRET: the contest disappears from home/archive/status, and even the scoreboard requires login. For contests that must not even be known to exist.

⚖️ Judging (languages, pool, manual verdict)

• 💻 Languages allowed in the contest: the list of allowed languages in the contest. A problem can have its own list, in Contest › Problems: that list applies INSTEAD of this one.
• 🖥️ Judge machines (pool): which judging MACHINES serve this contest (empty = any online judge). Do not confuse them with HUMAN judges (section 4).
• Judging priority and submissions in the queue: decides the contest's turn in the judging queue and the submission rule. You select it at creation. It is required in the creation wizard, which has no default (in TCP 2026 the official contest started as Public list and nobody chose it; through the API or the CLI, without the field, Public list applies). You can change it here at any time, at the end of the ⚖️ Judging section. With Public list or Private list, each team has at most 3 submissions waiting for a verdict: the 4th one is refused until a result comes out. This protects the judge from accounts that resubmit without a stop. With Contest, the contest is judged before the lists and there is no limit: from the 6th submission waiting for a verdict, the next submissions of that team go further back in the queue (as if they arrived 2 minutes later). Nothing is refused. A submission held for manual verdict does not count. The change applies to the next submissions. Only the training super-admin gives or removes Super (it jumps the whole queue), in Training panel › Contests: Super does not show here, and a contest on Super has a locked field. Every priority change goes to the contest Audit log and to the training trail, with who changed it, from which to which, and through which screen. The 🏁 Central shows the rule in effect (item "Submissions in the queue") and warns when an ICPC contest has no selected priority. The MOJ operator changes the limit of 3 in the conf: SUBMIT_MAX_INFLIGHT=<n> (0 turns it off).
• Manual verdict: turns on grading validated by human judges (section 4).
• Judges required to validate each verdict: the quorum of the manual review: 1 to 5, default 2. With 1, one vote decides (single review). With N≥2, the verdict goes out only with N unanimous votes. Any disagreement becomes a conflict for the chief judge.
• ⏱ Penalty (ICPC scoreboard): the minutes added per non-accepted attempt before the Accepted (default 20), and WHICH verdicts count as penalty (default wa/tle/mle/rte: Compilation Error is OUT by default; empty = nothing counts).
• 👁️ Full scoreboard (no freeze): an allowlist of logins that see the scoreboard without the freeze (in addition to admin/judges).

Save writes only what changed (the Audit log records only that). If an option is wrong (for example, a time zone that does not exist), nothing is written and the message tells which option to correct.

In the CLI, all of this is moj contest -c <cid> settings set chave=valor (for example: settings set manual_verdict=true review_judges=3).

3. Special roles: what they are and how to enable them

To enable a role, create the account with the correct suffix in the login, in the People › Accounts panel (or moj contest -c <cid> users add fulano.judge). There is no permission checkbox: the suffix IS the role. The public self-registration never creates accounts with these suffixes (they are reserved). Bulk operations (password reset, disable) skip privileged accounts on purpose.

Golden rule: no account with a role suffix goes to the scoreboard or to the statistics. Create as many as you need: they do not change the result.

Alert for the organization on any page. Admin, chief judge, judge and .mon get, on any page of the contest, a bar at the top with a sound: 💬 unanswered clarification (all these roles), ⚖ verdict awaiting your vote (admin, chief and judge, when manual verdict is on) and ⚠ conflict (admin and chief). The count also shows in the title of the tab. The sound plays again every 2 minutes while items are pending. The bar has the buttons to enable or mute the sound and to ask for the system notification. The scoreboard reveal, the Animeitor big screen and the editor window do not show the bar. More information in MANUAL-JUIZ.md.

Contest with users shared with Free Training: a role account of the training site does not get in with its role here. Only the .admin of the person who created the contest and the training superadmins get in. A judge, a staff member or a co-organizer = an account that you create in this contest (section 8¾).

4. Grading validated by judges (manual verdict)

With Manual verdict on, the automatic judging continues to run, but the verdict is held: the student sees the submission as pending until human judges validate it.

The flow, in the Judge tab (the .judge page):

1. The judge claims a submission from the queue (a reservation with a deadline; max. N judges on the same submission).
2. The judge sees the computed verdict, the log and the code, and votes (confirm, or change the label).
3. When N unanimous votes accumulate (N = Judges required to validate each verdict, default 2), the verdict is released. It goes to the history of the student and to the scoreboard immediately.
4. Different votes become a conflict: the chief judge (.cjudge) decides in the chief judge panel (a global alert gives a warning).

Verdict options. The chief judge or the admin edits the list in 🏷️ Options (chief judge panel or Operations › Judges). Each option has three fields:

1. The text that the judge sees and selects. Example: 5 - NO - Wrong answer.
2. The class: one of the six canonical classes. The class sets the score, the penalty and the color on the scoreboard. Example: Wrong Answer.
3. The text that the team sees. Example: Formato de saída errado. Leave it empty to show the class. The Accepted class has no text of its own.

Thus each contest customizes what the team reads, without a change to how the scoreboard counts points.

How many persons do you need? At least N .judge accounts (the quorum) + 1 .cjudge for conflicts. I recommend N+1 judges, so that the queue does not stop when a person takes a break. The .admin also votes (it counts as a judge), but in a large contest keep the admin free to operate. With N=1, one judge reviews everything (good for a small contest). N=2 is the balanced default. N≥3 is for finals where the verdict needs a panel.

5. Contest documents (Event › Documents — module documentos)

The tab exists for the .admin and for the chief judge (.cjudge). It produces the contest documents, each in PDF and HTML, in Portuguese, English and Spanish:

Flow, from start to end

1. Fill in the data (⚙️ Document data): problem set version (v1.0), cover note and errata. Save.

2. Adjust the cover, if you want (🎨 Problem set cover). There are two modes, in this order of precedence: uploaded PDF › text. The text opens with the MOJ default cover: it is that cover, written in Markdown, so you edit only what you want to change. The markers are replaced when MOJ generates the document: {{CONTEST_NAME}}, {{DATE}}, {{N_PROBLEMS}}, {{N_PAGES}}, {{SITES}}, {{VERSION}} and {{NOTE}} (the cover note). {{N_PAGES}}, {{SITES}} and {{NOTE}} are optional: when one of them is empty, its block disappears. Upload a PDF when the cover is finished artwork of the event. It goes in as it is, and the rest of the problem set is attached after it.

   Logo (🏷️ Header logo, optional): a strip with the event logos (PNG, JPEG, WebP or SVG, up to 5 MB). It goes at the top of each page of the problem set and of the editorial, and on the generated cover, as in the Maratona SBC problem sets. It applies to the three languages; remove takes it out.

3. Adjust the info sheet text, if you want (📝). It is also Markdown, with the markers {{TOOLCHAIN}}, {{TL_TABLE}}, {{LANGS_TABLE}}, {{MEMLIMIT}}, {{STACK}}, {{CONTEST_NAME}} and {{DATE}}.

   The two texts use the MOJ editor (Markdown colors and line numbers), with one tab per language (PT · EN · ES), as in problem management. Save saves all the changed languages. restore default gives the language of the tab back the MOJ text.

4. Generate (the button of each line, or ⚙️ Generate all (pt+en+es)), or upload a finished PDF (the upload PDF button of the line). The uploaded PDF is a complete document. It overrides the generated one in all that MOJ serves, and you can publish it without generating. back to generated deletes only the uploaded file (on a published document with no generated PDF, MOJ refuses: generate first or unpublish). The conversion to PDF takes some seconds. The problem set takes the longest, because it joins one PDF per problem. If the conversion to PDF fails, the message tells which document failed, and the previous PDF (if there was one) stays the file that all persons download.

5. Check: each line has PDF, HTML and open. Review before you publish. Something wrong in the generated PDF, such as too much or too little space between the elements, or a large image, caused by the Markdown of the statement? Each generated document also has the ✎ .odt, the editable file that the PDF came from. Download it, adjust it in LibreOffice (or Word), export it to PDF and upload it with upload PDF. The uploaded file overrides the generated one, and it is the file that all persons download. The .odt of the problem set has the cover as an editable page, followed by the statements. If the cover is an uploaded PDF, or a problem has its own PDF statement, the .odt marks the place, and you join the PDF when you export. Only the admin and the chief judge can download the .odt.

6. Publish (only a document with a PDF, generated or uploaded). Publishing does two things: the document appears in the Contest section of the contest page and in Documents. Who sees what:

   • Judging environment: published = visible to all roles (it is logistics).
   • Problem set and time limits sheet: before the START of the contest, only .admin, .cjudge and .judge can download them. The site (.staff, .cstaff), the .mon and the teams only from the start. A problem set in the hands of any person before the contest is a leaked contest, for any role. The site prints from the start (the + news of these two documents is refused before the start, because the news item attaches the PDF).
   • Editorial: it is published only after the end, and only the judges can download it before the contest ends for ALL sites. If you check + news, MOJ also creates a news item with the PDF attached (the PDF that all persons download: the uploaded one, if there is one). Unpublish undoes this: the link disappears, and the news item with the attachment of that document disappears too.

Did you generate again? You do not need to publish again. The published link points to the current document, so a new generation delivers the new version to the next person who downloads it. But tell the site: the persons who already printed it have the old version (this is why the cover has the problem set version field).

🌐 The problem set and the editorial are in the language of the document. The English problem set uses the enunciado.en.md of each problem (or the English HTML/PDF that you sent in the Problems panel), and the English editorial uses the solucao.en.md. A problem without a translation is in Portuguese in the middle of the problem set: the document never has only the cover translated. The problem title is translated when the package has the title in that language. A bilingual contest with statements prepared outside MOJ continues to use the uploaded PDF.

∑ The formulas in the PDF look as in the statement on the page, including the vertical bar (|x|, a | b). The author does not need to escape anything. If a formula symbol shows as a red ¿ in the PDF, this is a defect of the generator, not of the statement. Report it (with the problem) and, in the meantime, upload the finished PDF of that problem set. A problem set generated before a fix does not update itself: generate it again.

🖼 Statement images fit on the page. In the PDF, each image is at most the size that it has on the web page, and never larger than the usable area (a large image is reduced, with the same proportions). The width that the author set in the statement (![](figura.png){width=50%}) also applies in the PDF.

🔒 The problem set is contest content. Before it is published, only .admin and .cjudge can download it. After it is published, before the start only the judges (.judge) are added to them. For the site and the teams, the API responds 404 until the start: this is not an interface lock.

6. Rounds: warm-up and official contest (Event › Rounds — module rodadas)

Every programming marathon has a warm-up (dress rehearsal) before the contest: two or three easy problems, on the day before or on the morning of the contest. The team uses it to turn on the machine and to test the login, the editor, the printing and the balloon. Your team of judges and staff also rehearses. After that, the contest starts in the same contest, because you want to be sure of its configuration (accounts, passwords, sites, balloon colors, time limits, languages, judge pool).

In MOJ, these are rounds. The live round is the one that appears in Home › Rules and in Contest › Problems. The other rounds stay planned until you promote them.

The procedure (note the order: the warm-up comes FIRST)

1. Set up the contest as usual, with the warm-up problems and the warm-up window.
2. In Event › Rounds, give the correct name to the live round (aquecimento, type warm-up) and create the next round (oficial): window, freeze and the list of problems of the real contest. MOJ keeps the list and puts it live only at the promotion: nobody sees the contest problems before. You can use any problem that the contest owner can see: public, his or her own, of a collaborator or of his or her org. The rule is the same as in Contest › Problems, for the live round and for the planned round. Each round can have its own balloon colors. Open the round, go to "🎈 Balloon colours for this round" and save. The colors go live when the round is promoted. A round without its own colors inherits the current colors. For the live round, this section and Event › Balloons edit the same data.
3. Run the warm-up. The team sees a fixed banner that tells that this is a warm-up and that this scoreboard is not the contest scoreboard. Use it as a full rehearsal of the whole operation. If the login opens at the minute of the start (ICPC model), this is the only moment when each role uses the real screens with nothing at stake. Before it, give each person the tutorial of his or her role (/contest/ajuda/), and ask each person to do his or her own list: the team (log in, open a problem, submit on purpose, clarification, printing, backup, scoreboard), the room staff (printer, the pop-up allowed, kiosk, the route), the site chief (every team of the site logged in at least one time), the judges (verdict options, log/code, the pair reads the same), the chief judge (number of judges, what goes to review, conflict alarm) and the big screen (projector, connection to the Animeitor — publish the scoreboards and turn on the feeder —, photos and music).
4. When it ends, click 🚀 Promote now. MOJ checks the checklist and, if all is ready:
   • it archives the round: submissions (with source code), verdicts, judge log, scoreboard, statistics, clarifications, news, staff tasks and the access logs are kept in rounds/<rodada>/, plus a browsable report of the round;
   • it resets the scoreboard and the history of the teams, restarts the print numbering and clears the extensions by site;
   • it applies the window and the problems of the official contest, and its balloon colors, if it has them. Caution: with the scoreboard frozen, MOJ accepts the promotion only from the end of the contest for all sites + 1 minute. The checklist shows freeze_locked with the time. The "ignore blockers" option does not override this rule. You type the contest id to confirm. MOJ audits all of it.

I registered the CONTEST first. What now? Did you set up the contest with the official contest first, and create the warm-up round only after? Do not promote. Promotion archives the live round (your contest, empty), and an archive cannot change. The correct procedure is to swap them by editing the two rounds in the same panel (the panel warns you when it finds a planned round that starts before the live round):

1. Edit the planned round: rename it to prova, type official contest, and give it the window + freeze of the contest. In Round problems, put the list of the contest problems (MOJ keeps it, and nobody sees it).
2. Edit the live round: rename it to aquecimento, type warm-up, warm-up window (no freeze), and replace the problems with the warm-up problems. For the live round, saving applies immediately.
3. In Home › Rules, make sure that the current window is the warm-up window. Then follow the normal procedure from step 3.
4. After: the scoreboard and the submissions of the warm-up stay readable in Rounds (and you can publish the round so that the teams see it). The raw archive in .tar.gz, with source code, is one click away, for a later audit.

The checklist is serious. The promotion REFUSES while there is:

There is a --force (the "ignore blockers" checkbox) for emergencies. It does not remove the risk: it only assumes that you know what you do. The only blocker that --force does not ignore is no_next_round (without a planned round, there is no round to promote to).

Did you promote by mistake? Undo it. In Event › Rounds, the card ↩︎ Undo the last promotion (or moj-contest rounds undo) brings the archived round back live with everything it had — submissions, verdicts, clarifications, prints, scoreboard — and the round that went live goes back to planned. It works only while the round that went live has had no activity (no submission, clarification, print or notice); if not, the card tells what happened in it. You type the contest id to confirm, and it goes to the audit. This was the case at TCP 2026: after the contest, the organizer created an extra round and promoted it, and the scoreboard went back to zero.

A contest that uses the accounts of another contest (USERS_FROM) promotes normally: the archive changes only the local users/. This was a blocker before. It is not a blocker now, because this is the real use case (warm-up + contest with the training accounts).

What does NOT change at the promotion: accounts and passwords, teams/sites/flags, staff scope, balloon colors, regions, calibrated time limits, languages, judge pool, the table of what goes to review and the texts/cover of the documents. What is reset: the scoreboard, the history and the submissions of the teams (archived, not lost), balloons, print numbering, extensions, and the list of published documents.

⚠️ Balloon colors are per LETTER. If problem A of the warm-up and problem A of the contest are different, the color of balloon A is the same in the two rounds. Check it in Event › Balloons before the contest.

In the CLI: moj contest -c <cid> rounds ls | add | set | problems | promote | publish | archive.

6½. After the contest: finish the event

When the contest ends, the scoreboard stays frozen and the documents stay not published until a person releases them. None of this occurs automatically with the clock. Home then shows the "🏁 After the contest" block, with the checklist of what is still closed, and the 🏁 Finish event button. This button does at one time the two things that everybody forgets:

1. it opens the scoreboard: it removes the freeze (FREEZE_TIME=0), so the final result becomes public (this has the same effect as the "🔓 Unfreeze all (public)" button of the reveal ceremony). MOJ accepts the unfreeze only from the end of the contest for all sites + 1 minute. The extension of a site counts. The rule applies to all paths: this button, the ceremony, the freeze field in Home and the round promotion. The screen shows the time from which the button is available;
2. it publishes the documents already generated that are not published yet: problem set, time limits sheet, info sheet and editorial appear in "Files & Resources" for the teams. (The editorial can be published only after the end; this is why it is included here.)

The button does not change the rest. Release of the judging report to the teams (SHOWLOG), display of the time limits and release of the cohorts (guest teams) stay your decision. Each one appears in the checklist with a "fix →" shortcut to the correct screen. The button runs only after the contest ended for all sites (extension by site counts), and you can use it again as many times as you want: the second time, it does nothing.

The final report closes the cycle (Contest › Report). The browsable tar.gz contains the open scoreboard, the submissions, the full statistics, the statements and the published documents. This is the package that you send to the participants and to the event archive. Next to the download there is 📢 Publish as history. The same site then exists at https://moj…/relatorio/<contest>/, and the contest card on the home page and on /contests/ gets the 📑 Report button. It is the history of the event. The generation runs in the background (~1–2 min for a large contest; the panel shows "publishing…" and changes automatically when it ends). It is public. The report does not contain source code, judge log or passwords, and the clarifications are anonymous. But it shows team names, runs and statistics: publish it when all has been announced. 🔄 Republish generates it again and replaces the full site at one time (a reader does not see a half-done site). Unpublish deletes the address and the button of the cards. The archived rounds (warm-up, for example) have their own button in Contest › Report: 🌐 publish puts the report that the promotion generated at /relatorio/<contest>/rodada/<slug>/. When the main report is (re)published, its home page links the public rounds in "Earlier rounds of this event".

MOJ refuses to publish the report when it would show what is not public yet:

• Before the contest starts. The report contains the statements.
• With the scoreboard frozen, until the end of the contest for all sites + 1 minute. The report shows the full scoreboard. After that, if the scoreboard is still frozen (the reveal did not occur), the panel asks for confirmation.
• With a PRIVATE cohort and the results not released. The report shows all the teams. This also applies to the report of an archived round. Release the results in Event › Cohorts.

6¾. Virtual participation (Event › Virtual — module virtual)

After the contest ends, any Free Training account can do the contest again one time, in its own time, against the official scoreboard. The official scoreboard does not change. Full reference: docs/VIRTUAL.md.

To turn it on: Home › Modules › Virtual participation. The module turns on only when:

1. the contest is not secret;
2. the mode is ICPC;
3. the scoreboard is not anonymous;
4. the contest has a start and an end;
5. all the problems are already public in the training. If one is not, the response is an error that tells how many are missing. Publish the problems first (problem management) and turn the module on again.

The module card shows a lock and what is missing, and the Home checklist warns about a module that is already on without it. At creation (spec, template or copy), a contest that does not meet these conditions starts with the module off, and the result screen (or the CLI) tells why: turn it on later in Home › Modules.

You can turn on the module before the end of the contest (with the problems already public). It stays inactive and opens automatically when the contest ends for all sites and the scoreboard is unfrozen (the Finish event button). The Virtual button on the contest card and the notice on the scoreboard show only when virtual participation is possible.

Caution: this module makes the final scoreboard and the problem list visible to training accounts. A contest that must not be seen from outside must not turn on this module.

The Event › Virtual panel shows:

• the conditions, one per line, with ✅ or ⛔. The public sees only "unavailable"; you see what is missing;
• the link to the page (/treino/virtual/?c=<contest>);
• the recorded participations, with solved problems and penalty. The remove from board button removes a row from the virtual scoreboard (the record stays; restore undoes it). The action is audited. The give attempt back button deletes the row and lets that account start again in this contest. Use it for a tester, or for a person who had a problem during the contest. This action is also audited.

Participant rule (the participant reads it before the start): one participation per account. The participant can give up without a record in the first 15 minutes, or while he or she has no accepted submission, at most 2 times. The 3rd start is final.

7. Team machines (Machines › Gate & lock — module maquinas)

The warm-up is when the teams really turn on the computers. From it, MOJ gets the room map team × IP × browser (from the contest access log, cut to the round window: MOJ captures nothing new). The tab shows, per round:

• per team: name, site, IPs and browsers used, first login, and an alert when the team used more than one IP;
• per IP: which teams came from each machine. It marks a shared IP (two teams on the same machine is a sign of a swapped desk or a borrowed account);
• who changed machines: in the official contest, a team that logs in from an IP/browser different from the one it used in the warm-up is marked in red;
• ⇣ CSV of all of it, to compare with the spreadsheet of the site.

Two actions start here, and they write to the usual place:

• set site: in the per-IP view, type the site name and click. This saves the site of the teams of that IP (the same field as in Event › Teams). The scoreboard, the badges and the staff scope then use it;
• configure the browser gate: the 🔒 section at the top of the tab (just below). The browsers actually seen in the round are listed there, and you can make each one the fallback with one click.

The gate BY SITE (the programming marathon case)

When each site runs its own image, the UA of each machine contains a part of the team login: teambrspso001 (Brazil/BR, São Paulo/SP, Sorocaba/SO) runs on an image whose UA contains brspso. One substring is not sufficient, so MOJ derives the expected value from the login.

On the web (🔒 section of Machines › Gate & lock): the mode is Off, Observe or Block. Observe shows the expected × seen UA and "UA off-site" in Anomalies, without blocking anyone or ending a session: you can turn it on during the contest to check the room. Block makes the login return 403. Below are the login regex (with capture) and the expected UA (\1), with a live tester ("test with login" → UA must contain brspso · site Sorocaba), and three collapsible lists: per-site overrides, login regex rules and exempt. When you save, it applies from the next login. With no rule, the gate does nothing: the panel says "no rule: nobody is blocked or observed", MOJ refuses to save Block or Observe without a rule, and the 🏁 Home warns when the maquinas module is on with no saved gate (save Off if this is intentional). This occurred in TCP 2026: the old panel showed "active" with no rule at all.

In the CLI, the same:

moj contest -c <cid> ua-gate set --from-login '^team([a-z]{6})[0-9]{3}$' --expect '\1'
moj contest -c <cid> ua-gate set --region 'Sorocaba=brspso-v2'     # site outside the pattern
moj contest -c <cid> ua-gate set --exempt '^ccl' --exempt time-reserva-07
moj contest -c <cid> ua-gate set --mode observe                     # look without blocking (enforce = block, off = turn off)
moj contest -c <cid> ua-gate check teambrspso001                   # what MOJ expects from it
moj contest -c <cid> ua-gate show

One rule covers all sites at one time. The resolution order is: exempt › role account (always gets in) › regex rule › site override › capture in the login › single substring (the usual login_ua_substring, which continues to apply as the last option).

• In Block mode, a login that does not match is blocked at login (403), with the exempt list as the margin. In Observe mode nobody is blocked: a login outside the pattern shows up in Machines › Anomalies. A safe procedure is Observe during the warm-up (check the room) and Block during the contest. --mode off turns off the gate without deleting the configuration.
• The Machines › Gate & lock panel shows the expected UA × seen UA per team, and counts how many are outside the site image. This is how you fix the room in the warm-up, before the gate blocks a team in the contest. The ✓ means that ALL browsers seen for that team are the site image; with one outside, it shows "partly off-image".
• With team registration, the gate checks a member against the expected UA of the team (the site and the login pattern belong to the team account).
• To log out a team that is already logged in with the wrong browser, use "Log out mismatched UA" (Machines › Anomalies). It compares each session with the expected value of that team.
• Per-site IP lock (switch in the same 🔒 section, OFF by default; turn it on for the contest): the gate and the subdomain isolation do not stop curl --resolve moj…:443:<IP> from the contest machine to the base site (training, backups that the student uploaded before, another contest). With the lock, each competitor login pins the source IP (the exit of the site) to this contest until the end + a margin (with rounds, until the end of the last planned round: an IP pinned in the warm-up stays pinned in the official round). From that IP, any other target responds 403 site_locked, also a training session opened before. Role accounts are exempt. Every claim and every block goes to the audit (site-lock-claim, site-lock-block). They appear in Machines › Gate & lock (site lock), with "release" per IP and "🔒 Pin IPs already seen" (useful on the morning of the contest). An accepted side effect: during the window, all persons behind that public IP lose access to the training.
• Single session per team (switch in the same 🔒 section, on by default): with the gate in Block mode, a new login on another machine ends the previous session of the team. A change of machine because of a defect continues to work (the team logs in on the new machine, and the old one loses the session). A page reload on the same machine ends nothing. Each ended session becomes an event in Machines › Anomalies.

7¼. Sites (Event › Sites & schools — module sedes)

The site of each team feeds the scoreboard filter, the staff scope (region:<name>), the badges, the per-site browser gate, the statistics, the classification and the big screen. All of them use the same rule:

1. the site stored on the team wins (the name, not case-sensitive);
2. otherwise, the deepest regex that matches the login (not case-sensitive);
3. a group/country adds up the sites below it; a node with the same name as the site also counts it;
4. a stored site that does not exist in the tree shows as "outside the tree" and counts in the node that the regex gives;
5. a cut (view: super-site, women teams) groups teams that are already in the sites, and it is never the site of a team.

The panel has three modes. Choose the mode that is sufficient for your contest; you can go up a mode at any time. A mode that does not fit the current tree is disabled and tells you why.

• Simple — a list of sites. Each site has "logins that start with" (comma-separated). To assign teams, paste the list of logins and choose the site, or choose the site of each team without a site. When you rename a site, the teams stored with the old name move with it (the preview shows how many before you save), and so do the staff scope (region:), the browser gate of the site and the big-screen site. When you save, the screen warns if something still points to a site that does not exist. By the IP of the contest machine: Machines › Gate.
• Intermediate — groups (country, region) › sites. Each site has rules: starts with, contains, ends with, or is one of (list).
• Advanced — the whole tree: sub-regions, view cuts and free regex.

The preview below shows what the scoreboard, the badges and the staff scope will see: how many teams each site has, who has no site, who stopped at a group/country (the regex matched the group and none of its sites), who matches two sites, and the stored sites that are outside the tree. "To save" summarizes the change. If another tab or the CLI changed the sites after you opened the screen, the save refuses: reload and do it again.

A registered team keeps its site in the registration: the site does not disappear when the team changes. The Home shows the item Sites when there is something to check.

The regex follows a subset that matches the same in the browser and on the server: \d \w \s and (?: are accepted; \b, (?=, [[:class:]], lazy quantifiers, an ambiguous hyphen inside [ ] and accented letters are not (logins have no accents). The save tells you which site and why.

In the CLI: moj-contest -c <id> regions show|who|assign|set|map.

7½. Machine anomalies (Machines › Anomalies) and Sessions (People › Sessions)

In the Maratona 2026, the question "did a team use two machines?" had an answer only after the contest, with a manual cross-check of logs. The Machines › Anomalies panel answers it during the contest (the active sessions, the mass logout and the access log, which apply to ANY contest, are in People › Sessions). The browser of the mlinux image identifies the machine (machine_id/boot_id), with or without the gate. A login from a common browser has only the IP, and behind NAT the IP is the full site. These logins stay out of the machine anomalies (they appear only in "UA off-site" and in the session list). "UA off-site" needs the expected UA of each team, that is, the gate in Block or Observe mode. When no machine is identified, the panel shows a warning and shows only the sessions and the access log.

• Cards (click = filter): active sessions, 👥 2 live sessions (the same team on two machines; with single session on, this occurs only with a copied token), 🖥 shared machine (2+ teams logged in on the same machine in the contest; serious if the two sessions are live on it), 📤 submission from another machine (the submission came from a machine different from the one that made the login; the same machine after a restart appears as info), 🧭 UA off-site, 🏫 site short of machines (from the last nutellaboot collection), 🔁 switched machine (info: normal when a machine fails) and the revocations of the single session.
• Timeline: each event with time, type, team, machine and detail; filters by type and text; CSV; a log out button for the team.
• Explain (admin and chief judge): a case that is already clear (e.g. "switched machine after a failure, confirmed by the site") gets the reason, leaves the counts and stays in the list, dimmed, with who explained it, when and why (✓ explained card; undo counts it again). If the case changes (the team goes to a third machine), it comes back. Each mark goes to the audit.
• Teams: only the teams with an anomaly (or all with a session): live sessions and on how many machines, the machines used in the contest in order, the last submission (✓ came from the machine of the session; ✗ did not) and the anomalies as tags.
• 🚪 Mass logout and login lock: the round change in three clicks. Close login (a competitor gets 403 login_disabled; the organization gets in). Log out competitors, staff and site chiefs or both (never admin, judges, chief judge, monitor or big screen). Promote the round in Event › Rounds. Then reopen login when the teams can get in. Each ended session becomes an event in the timeline; the action goes to the audit (logout-all).
• 🔒 Site lock: the IPs pinned to this contest (logins, blocks, until when), the recorded blocks (when, IP, target, route, session) and the release and 🔒 Pin IPs already seen buttons. The "lock blocks" card and the 🔒 events of the timeline come from the audit. Section 7 explains it.
• Request channel in the contest: how many contest logins and submissions came from the web, from the CLI (moj-comp) and from offline packages. This applies also without a gate. The CLI identifies itself in the User-Agent (moj-comp/<build>). On the contest machine, it sends first the same User-Agent as the browser of the image (read from /etc/moj/user-agent, which the image writes). This is how it passes the gate by site and gets the same machine key as the browser: if you use the two on the same machine, the session does not end. Outside the contest machine, the gate blocks the CLI (403), on purpose.
• It refreshes automatically every 30 s. The submission records its origin (IP, browser and the session used) in var/submit-origin.log; the logins go to var/access.log; the ended sessions go to var/session-events.log. The three logs continue across the rounds and go into the archive.

8. Guest teams (scoreboard cohorts — Event › Cohorts, module coortes)

A programming marathon invites teams that compete without being in the official competition: people call them guest, unofficial, "CCL". MOJ handles them as a cohort: a group of teams with its own visibility policy.

What a private cohort guarantees

• its teams do not appear on the public scoreboard;
• the regular teams do not know that it exists: not on the scoreboard, and not in the team directory (/contest/teams, which is public and listed every login);
• the guest teams themselves see all teams (their scoreboard shows official + guest teams);
• when you release the results, everybody sees all teams, and a guest team appears placed by its performance but without taking an official position: the combined podium continues to agree with the official one.

How to configure it (Event › Cohorts)

One row per cohort, with the fields that set the behavior: id, name, login regex, public (appears on the public scoreboard), unranked (included without taking a position), default (a team that matches nothing goes to it) and sees: the checkboxes that tell which cohorts that view sees (a cohort always sees itself). The teams column counts how many teams are in each cohort.

• + create cohort: it starts private and unranked, and it sees all. This is the CCL case.
• Number guest teams in their own sequence: by default, a guest team shows – in place of the position. With this option on, it shows its position among the guest teams, in italics, on the scoreboard, in the reveal and in the report. The official numbering does not change.
• assign: select a team and its cohort (the field overrides the regex). "— by rule (regex) —" sends the team back to the regex.
• 📌 Materialize (N): records the cohort of each team that now matches only by regex. After this, a change to the regex moves nobody. The counter tells how many teams are in this situation.
• 🔓 Release results: asks you to type the contest id to confirm (in practice it cannot be undone: the public scoreboard then shows all teams).
• Generated scoreboards: the views that build.sh maintains (one per cohort that sees a different set, plus the public one).

To change the default cohort, select the radio button of the other row and save that row. To remove a cohort, it must be empty (and you can never remove the default cohort).

The same in the CLI:

moj contest -c <cid> cohorts ls
moj contest -c <cid> cohorts add ccl --name "Café com Leite" --regex ccl --private --unranked
moj contest -c <cid> cohorts assign timeconvidado07 ccl     # guest team without 'ccl' in the login
moj contest -c <cid> cohorts materialize                    # records the rule as a field per team
moj contest -c <cid> cohorts release                        # the "release everything" (asks for the id)

The cohort matches by regex on the login and/or by the .team.cohort field of each team (the field overrides). materialize changes the rule into data: after it, a change to the regex moves nobody. A team that matches nothing goes to the default cohort (the one of the official teams).

What stays complete, on purpose: these are privileged roles, and you need them: All Submissions, Statistics (including who solved first), the staff queue (the balloon of a guest team must be delivered) and the final report. Two practical results:

• the code of a submission is visible only to the team that sent it and to judge/admin. The old option "show the code of submissions to everybody" (SHOWCODE) was removed on 2026-09-18;
• to publish the archive of a round (Event › Rounds), the results must be released when there is a private cohort: the round report has the open scoreboard with all teams.

ℹ️ Two numeric channels remain. They do not hide identity, but they exist: the public status page counts the pending submissions of all teams, and the print task numbering is unique per contest (gaps show activity that the team does not see).

8½. Pre-registration and teams of 3 training accounts

This applies to a contest created with "Share Free Training users". When you turn on registration (People › Registrations → Turn on), the contest gets a door: a person who did not register does not get in (the API refuses the login; it is not only the screen).

How a person registers: on the main site, logged in to the training, at /contests/inscricao/?c=<id> (the contest card on the home page gets the 📝 Register button). The person selects individual or create a team: gives a name and invites up to 2 training logins. Each invited person must accept. While the window is open, it is possible to leave, rename and undo. Participation is exclusive: to accept an invitation cancels the individual registration.

The invitation sends notifications automatically. At the moment when the captain invites, the mojinho sends a DM to the invited person, with the accept/decline link. On the day before the close (24 h before), it sends one last notification to the persons who did not answer yet (the message is in Portuguese; if the contest has LOCALE=en, it is in English and Portuguese in the same text: a DM has no language selector). It reaches only persons with a linked Telegram account (training profile → 📨 Telegram). This is why the invitation list shows 📨 (reachable) or ⚠️ (no channel), and the summary counts how many have no channel. In the team table, each pending invitation has the 🔔 button to nudge the person immediately, and the header has 🔔 Remind all. A manual nudge does not cancel the automatic notification of the day before. To turn off the automatic notification for this contest, clear automatic reminder in the window box (this saves REG_REMIND=n). This is important because a person who does not accept the invitation is not in the team, and sometimes is not even registered.

In the contest, each member logs in with his or her OWN training login and password, and the session becomes the team session: the scoreboard, the balloons and the printing see one row only. MOJ records who was at the keyboard (var/actor-log and the 5th column of var/access.log), which is useful for a later check.

The window (People › Registrations → Registration window): opens (empty = already open), closes (empty = the contest start) and late (min): the minutes after the start during which a person can still get in, but in the …-atrasado cohort. This cohort appears on the scoreboard without taking a position (it is the extra registration of Codeforces). After that, the door closes.

Which clock these fields use: the clock of your browser. The box shows which one, just below. But the times that MOJ writes for people (the mojinho DM, the pre-contest checklist, the date of the problem set, the final report) use the contest timezone. You set it in Home › Rules → 🕒 Identity and window → 🌎 Contest timezone (empty = America/Sao_Paulo). When the two clocks are different, the window box also shows the time in the contest timezone, so there is no doubt. Type the name of any timezone (America/Santiago, America/Mexico_City…). The list suggests all of them, starting with your browser's. Use your own city's timezone, not another one that has the same time today: daylight saving time changes on different dates in each country, and the texts would be 1 h off after the change. You can also select the timezone in the creation wizard, and it goes with the contest when you export, duplicate or save a template. From the CLI: moj-contest -c <cid> settings set tz=America/Santiago.

Scoreboard: registration creates the individual and times cohorts, each with its own scoreboard. The "Board: Overall | Times | Individual" selector appears automatically on the scoreboard page. If the contest already had cohorts, the pre-contest checklist warns that these two are missing.

With a WARM-UP (a warm-up that stays live for days): plan the two rounds in Event › Rounds (warm-up now, official contest on the real date). By default, the warm-up also requires registration. It is in the warm-up that the competitor solves login, submission and scoreboard problems. To let persons in without registration only moves the problem to the contest day. Registration closes automatically at the start of the official contest (this is the date that "closes" inherits, not the warm-up date). If you prefer a warm-up with an open door (any account of the source gets in without registration), set REG_WARMUP_OPEN=y in the conf. In this case, the promotion ends the session of each person who did not register, and the contest scoreboard starts with only the registered persons. While this applies, the panel shows the 🔥 warm-up: open door badge.

The participation mode is final: after registration (individual or in a team), the competitor cannot cancel or change the mode alone. The registration page makes this clear before the choice, and any change goes through you (People › Registrations: remove, dissolve, register manually).

The team also declares at registration: the university (it becomes the prefix [SIGLA] Nome do Time on the scoreboard, and the school column/filter), the use of AI (it appears as 🤖 next to the name: it is transparency, not judgment), the flag (country or Brazilian state: the small flag on the scoreboard) and a team photo (the one that goes to the big screen; the server processes it again, without metadata). The captain can edit all of this while the window is open, and it is visible in your panel and in the CSV. The INDIVIDUAL registrant declares the same data (except the photo): university, AI and flag, at registration or later, on the same page. The organization adjusts any of them with the team-meta/ individual-meta actions of the panel, without a regex rule in teams-meta.json (the legacy mechanism continues to apply only as a visual overlay).

Contest-day tip: the Home checklist shows how many persons registered and how many invitations are pending. A pending invitation means a person who thinks that he or she is in the team and who, at the time of the contest, cannot get in.

8¾. Accounts shared with Free Training: choose and undo

When you create the contest (step 3 of the wizard), you choose between own accounts of the contest and users shared with Free Training. With shared users, each person logs in with the account and the password of the training site. This is practical for an exercise list. For an exam, know the consequences:

1. The login and the password are the Free Training ones. You cannot see or reset them, and the badges show no password.
2. Any Free Training account gets in. To limit this, turn on the Registrations module (section 8½).
3. Only your .admin (the one of the person who created the contest) and the training superadmins get in with a role. A judge, a staff member and a co-organizer need an own account of the contest (People › Accounts, section 3).
4. There is no exam-wide password change. A person who knows the training password of another person also gets in as that person here.
5. You can undo this: convert to own accounts (below). You cannot undo the conversion.

The wizard creates a shared contest only after you tick ☐ I understand. While the contest stays shared, the Home shows the item Shared accounts.

Act on a shared participant. In People › Accounts, a person who logs in with the training account shows 🔗 training. Disable blocks the person in this contest (the training account continues to work on the training site). Re-enable undoes this. Disqualify removes the person from the scoreboard. Remove blocks the person permanently: the person cannot come back with the training account. When you create or reset an account here, the password of this contest applies: the training password does not open that account in this contest any more.

Convert to own accounts (People › Accounts › the 🔗 Shared accounts card):

1. Preview the conversion. Nothing is written. The preview counts who gets an account (the persons with a folder in the contest, an open session, a line in the access log or a registration), the teams, the team members who lose their login, and the warnings.
2. Confirm. Before the contest, tick ☐ I understand. After the start, type the contest id. If the list changes between the preview and the confirmation (a person logged in), the screen shows the new preview and asks you to confirm again.
3. Download the CSV with the credentials immediately. The new passwords show only there and on the Badges.

What the conversion does:

• Each participant gets an own account with a new password. Only the name comes from the training site.
• Each team becomes one account (login time-…) with one password. The members cannot log in with their own accounts any more. A member who submitted becomes a disabled account, and the scoreboard row of that member stays.
• Your training .admin becomes an own .admin of the contest with a new password (the screen shows it).
• The registration closes and the roster goes to the archive.
• The history and the scoreboard stay. A person who logged in and did not submit now shows with zero on the scoreboard.
• A person who never entered the contest gets no account (add that person in ➕ Add).
• The training superadmins cannot get in to this contest any more.
• The open sessions continue. The option log out the sessions makes all participants log in again with the new password.

In the CLI: moj-contest -c <id> users convert (preview) and users convert --apply --csv creds.csv.

9. User template (enables all functions)

Paste it in the bulk load of People › Accounts (one line per account: login nome), or create the accounts one by one with moj contest -c <cid> users add <login> --name "<nome>":

juiz1.judge      Judge One
juiz2.judge      Judge Two
juiz3.judge      Judge Three (spare for the quorum of 2)
chefe.cjudge     Chief Judge
apoio1.staff     Print and balloons staff
sede1.cstaff     Site 1 chief (badges + reveal)
monitor1.mon     Monitor (answers clarifications)

Then: turn on Manual verdict (and adjust the number of judges) in Home › Rules. Give out the generated passwords. Each person logs in on the SAME contest screen and sees the buttons of his or her role.

9½. Training panel › Contests and who can create them

The administration panel of the Free Training (/treino/admin/, .admin account) has the 🏆 Contests tab. It lists the contests created with the interface, and it controls who can create contests and problems.

Who sees what. The rule applies in the API, not only on the screen.

• A super-admin sees and operates the contests of all persons. A super-admin is a .admin account listed in SUPERADMINS in the contests/treino/conf file (logins separated by spaces). Only persons with access to the server edit this list. There is no screen for it.
• A regular admin sees his or her own contests and the contests of creators without an admin role (students and allowed monitors). A regular admin does not see the contest of another administrator. Remove, duplicate and export follow the same rule: a contest outside your scope responds "not found".

List filters. Search by name, id or owner. Filter by owner, mode and state (upcoming, in progress, ended). Sort by creation date, start, name or owner. Check only mine to see only what you created. The owner appears with photo, name and a link to the profile.

Reserved id. An id that starts with icpc belongs to the Maratona organization. Only a super-admin can create a contest with this id. The wizard warns before, and the API refuses.

Priority (Priority column). The super-admin changes the priority of any contest directly in the table, including Super, which jumps the whole queue. This is the only place to give or remove Super. The wizard offers Super only to the super-admin, and a copy (duplicate) of a Super contest made by another account starts as Contest. The other administrators only see the column: the admin of each contest changes the other priorities in Central › Rules. Every change goes to the contest Audit log and to the training trail (📜 Activity feed, action contest-priority). From the CLI: moj contest priority <cid> <priority>.

Who can create contests and problems. The same permission applies to creating contests and to creating problems and collections in Problem Management. .admin accounts can always create them. For the other accounts:

• ✅ Allowed: type the login and an optional note, and click ✅ Allow. The account must exist in the training. Each row shows the person, who allowed it and when.
• ⛔ Blocked: the same, with ⛔ Block. A block overrides the automatic threshold.
• Automatic threshold (Auto-allow whoever solved ≥): a person who solved at least N problems can create. Zero turns it off.

10. References

• Judge manual: the operation of the Judge tab and of the chief judge.
• Room staff manual: printing, balloons, badges, reveal by site.
• Competitor manual: what the student sees (give it out with the passwords).
• Organizer tutorial: create the contest (wizard and CLI).
• Competitor CLI: submission from the terminal, with an offline mode.