Uniqueness

Each challenge has a folder in the repository. The folder has two types of solution:

• The solutions of other talents, in different languages. Each of these is an internal solution.
• A file OTHERS.lst with links to solutions on the internet. Each of these is an external solution.

A unique solution is a solution that you upload in a language that has no internal solution and no external solution. A solution that obeys all the instructions of this section gets the status unique solution.

A programming solution loses its uniqueness in one of these two conditions:

• A different talent adds an external solution in the same language to the OTHERS.lst file of the challenge.
• A different talent merges an internal solution in the same language.

CAUTION: Read the challenge folder before you start a programming challenge. If the folder already holds a solution with the extension of your language, your pipeline fails. The merge request cannot merge, and the question of uniqueness never arrives.

A ctf-hacking solution or a vbd-hacking solution loses its uniqueness in one of these two conditions:

• A different talent adds an external solution to the OTHERS.lst file of the challenge.
• A .feature file for the same challenge is already in the repository, or a different talent adds one.

If no unique challenge is available, you cannot merge a new unique solution. In that condition, ask for a change of site or a change of language.

Code uniqueness conflicts and recovery

Sometimes a solution of a different talent in the same language reaches the challenge first. It is an internal file with the extension of the language, or an entry in OTHERS.lst. Your pipeline fails if that solution merged before you push. A reviewer closes your merge request if it merged after you opened yours. The time that you used is not lost. You have two ways to recover it, and you select the better one for your current work.

Option A. Write the solution again in a different language. This gives you a separate unique solution, because the repository keys uniqueness by (challenge, extension). The algorithm that you wrote applies to the new language, and the translation cost is small. The effort of the new merge request must include the hours of the closed merge request. It must also include the hours of the new work.

Your policy sometimes does not permit the site of the new language. For example, your policy is default_hack, which permits only spoj for code, but the challenge is on codeabbey. In that condition, the new solution fails the test-policy check.

Build and test the new solution on your computer first. Then send a message to a reviewer. The reviewer gives you access to the policy for the time of the recovery. You push your work and open the merge request, and the reviewer removes the access after the merge.

Option B. Absorb the hours into your next merged solution. If you prefer to start a different challenge, add the hours to the effort of your next merged solution. That solution can be unique or not unique. This is the same absorption rule for an abandoned challenge. It applies to all other Academy work that does not merge, and the section Abandoned challenges below gives the procedure.

Option B gives you fewer unique solutions than Option A. However, it is better when a new implementation does not agree with your current work.

Both options keep Time Doctor and effort in agreement. Fluid Attacks measures the average time to make a unique solution. The attempts that do not merge are part of that average.

Hack uniqueness conflicts and recovery

For a ctf-hacking solution and a vbd-hacking solution, only Option B applies. Option A has no equivalent here, because the repository keys a unique solution by (challenge, .feature). Only one .feature file can stay in the folder of the challenge. When the .feature file of a different talent merges first, that challenge accepts no other .feature file.

Two talents sometimes work on the same hack challenge at the same time. In that condition, the team uses the created_at value of the merge request to select the order. When two merge requests are correct, the reviewers process the older one first. This is not a hard rule, but it is the default order. Thus, open your merge request immediately after your solution is complete. If you wait, your position in the queue becomes worse.

If your merge request merges first, the hours go to the effort of your YAML file in the usual way.

If the merge request of the other talent merges first, you cannot make a new YAML file for that challenge. Add the hours to the effort of your next merged solution. This keeps the sum of effort in agreement with Time Doctor at the level of the talent. The elevated effort does not agree with the difficulty of the solution that carries it. Thus the commit body must include this annotation:

- hack uniqueness conflict
- race lost on <chal>
- <X>h from the lost challenge absorbed into this solution's effort

Set <chal> to the identifier of the challenge that you lost. An example is hackthebox/devarea. Set <X> to the hours that you logged in Time Doctor on that challenge. Without the annotation, the elevated effort looks like an over-report at the audit.

Abandoned challenges

You can stop work on a challenge for any reason. These are some examples:

• The setup of the environment did not give a solution.
• You made an incorrect estimate of the scope.
• A rule of the procedure closed the merge request.
• The challenge is no longer interesting to you.
• You changed to different work.

The time that you used is not lost. The absorption rule applies: add the hours to the effort of your next merged solution. That solution can be unique or not unique. Fluid Attacks measures the average time to make a unique solution. The attempts that do not merge are part of that average.

Add this annotation to the body of the commit that contains the absorbing solution:

- abandoned challenge
- <chal>
- <X>h from the abandoned attempt

Set <chal> to the identifier of the challenge that you stopped. An example is codeabbey/099. Set <X> to the hours that you logged in Time Doctor on that challenge. The annotation makes the elevated effort possible to audit. Without the annotation, the elevated value looks like an over-report.

One rule controls all of this. The sum of the effort of your merged solutions must stay in a margin of your Time Doctor total. Terms gives that margin. The absorption keeps the rule true, so you do not have to write again all the work that you tried.