The Solver's Handbook

Decide whether a CI run may promote a container image, and prove it with a real workflow. This is the one question with two graded halves: the live probes carry most of it, the public workflow evidence carries the rest.

1. Collect, don't short-circuit. Unlike the other gates, this one wants all the violation codes for a payload. Build a list, append as you go, de-duplicate at the end, and promote only when the list is empty.

2. Permissions are set equality, not a subset check. Compare the whole permissions object against the exact required scopes. An extra scope, a missing scope, or a right key with a wrong value are all the same single violation.

3. The unsafe trigger is a fixed value. One specific trigger is never acceptable for a release gate; flag it whenever it appears rather than trying to infer intent from the event field. Don't over-fire on a merely mismatched event — that isn't the violation being tested.

4. Three test conditions collapse into one code. Tests passing, the matrix completing, and fail-fast being off are separate booleans but a single violation. Any one of them failing emits it once.

5. Pinning applies only to third parties. Actions under the first-party namespace may use a version tag. Everything else must match a full 40-character lowercase hex SHA — anchor the regex at both ends so a 39- or 41-character string fails.

6. The image checks are five independent gates. Build style, runtime user, how the build secret was supplied, critical vulnerability count, and digest pinning each emit their own code and can fire together.

7. Production adds two more, not one. The branch and event requirement is one code; the missing approval flag is a different code. A production payload can trip both at once.

8. Then build the evidence. Public repository, a workflow whose name: matches the required string character for character, a step whose name: matches its required string character for character, triggered on a push to the default branch, and actually run green. Submit the workflow page URL — the one that lists runs — not the URL of an individual run.

A compromised model proposes a tool call; you decide whether the tool actually runs. The entire point is that the boundary is structural — schemas, scopes, approval, safe rendering — and never a judgement about the text.

1. Implement that order literally. Return on the first failure. A payload that is both an unknown tool and badly shaped has one correct answer, and it is the earlier check.

2. Validate the envelope before the action. The provenance value, the approval boolean, and the action object with its tool string and args object are all part of the top-level shape. The optional untrusted-content field must be a string if it is present at all.

3. Argument schemas are exact. Exactly the listed keys — an extra key is as invalid as a missing one. Enforce the stated length bounds and non-empty requirements, and check both ends of a range.

4. Compare the tenant with equality against your own assigned value. Anything else is a scope failure, not a schema failure.

5. Take the recipient domain from after the last @, lowercase it, and compare with ==. A subdomain of the allowed domain, a domain that merely ends with it, a trailing dot, surrounding whitespace, or a second @ must all be refused.

6. Check approval after the domain, because that is the order the question gives, even though it feels backwards.

7. For rendered HTML, block exactly four categories: an opening script, iframe, object or embed tag; an inline event-handler attribute; and a javascript URL. Match the event handler in attribute position so ordinary prose doesn't trip it, and make sure a plain paragraph, a normal link and a relative image still come back clean.

One normalised resource change, reviewed before apply. Eight checks in a fixed sequence; the sequence is most of the difficulty.

1. Type-validate first. The body and every nested object must have the shown value types before any policy question is asked. Get this wrong and payloads that should be rejected for shape come back rejected for the wrong reason.

2. Match the workspace exactly, then move on. This sits ahead of the state and provider checks, so a payload with a wrong workspace and a bad backend answers with the workspace.

3. State means both things: a backend drawn from the allowed set and locking switched on. Either one failing produces the same single reason.

4. Pinning has exactly two acceptable shapes: a full three-part version, optionally with an equals sign, or a pessimistic constraint. Comparison operators, wildcards, and the word "latest" are unpinned — and so is a bare partial version with no operator at all.

5. Labels are a presence-and-value check. All three assigned labels must be there with exact values. Extra labels beyond those three are not forbidden by the wording, so don't reject them.

6. A secret is either null or a reference. A reference means the required scheme prefix plus something after it — the bare prefix with nothing following is still a failure. Anything else is a plaintext secret.

7. Destructive deletes need approval, but only for the three stateful resource types listed. Deleting anything else does not require the flag.

8. Force-destroy on a bucket is absolute. By the time a request reaches this check the workspace has already been validated as production, so no extra environment condition is needed.

Model output is untrusted input. Decide whether a string is safe to hand to a given sink. The hard parts are the decode pass and the hostname comparison — both are explicitly probed.

1. Schema includes a length bound. Body shape, channel membership, output type, and the maximum length are one combined check, evaluated on the original string.

2. Decode exactly once, in the stated sequence: percent-escapes, then the specific HTML entities the question names — numeric and the five named ones, nothing more — then unicode escapes. Do not reach for a full entity table; the spec is deliberately narrower.

3. The encoded verdict has two conditions. The decoded string must differ from the original and the decoded string must trip one of the channel rules. A percent-encoded but harmless string is clean, and that case is probed.

4. Then run the channel rules against the original, not the decoded version. Each channel has its own ordered list; markdown and URL share theirs, HTML has two extra checks in front, and the SQL and shell channels have a single check each.

5. Extract URLs per channel. Quoted source and link attribute values for HTML; the target inside the parentheses for markdown, images included, allowing for a trailing title; the whole trimmed string for the URL channel.

6. Parse the hostname and compare with equality. Lowercase it, drop a trailing dot, and test against your two allowed hosts. Subdomains are not allowed, which rules out any suffix test.

7. Treat protocol-relative references as absolute. A reference beginning with two slashes resolves against the page scheme and a browser will fetch it, so it goes through the same hostname check. Genuinely relative paths are fine.

8. The dangerous-scheme test is two tests. A literal scheme appearing anywhere in the text, tolerating whitespace before the colon, and any extracted URL whose scheme isn't HTTP or HTTPS.

Does the evidence actually support the claim, how confident does that make you, and which sources justify it. Every timestamp arrives in the request, which means the service must be perfectly reproducible.

1. Never read the clock. No current-time call anywhere in the module. Freshness is always the request's own reference timestamp minus the observation, compared against the request's own window. Grep your own file afterwards to prove it.

2. Validate the envelope into the "invalid" verdict. A non-object body, a non-string claim value, a missing or unparseable reference timestamp, a non-numeric window, or a non-array source list all land here — with the lowest confidence and an empty source list.

3. Drop invalid sources entirely, before anything else. A source only counts if its identifier, origin, value and observation timestamp are all strings and its type is in the allowed set. An unrecognised type doesn't weaken the claim; it simply isn't there.

4. Contradiction comes next, and needs three things at once: fresh, authoritative, and a value different from the claim. All such sources go into the returned list, sorted ascending — origin de-duplication does not apply here.

5. For support, filter then collapse. Keep fresh sources whose value equals the claim, group them by origin, and keep one representative per origin: the lexicographically smallest identifier. Two or more representatives surviving is what "corroborated" means.

6. Confidence is about type diversity, not count. Representatives spanning two or more distinct types is the high case; all sharing one type is the middle case.

7. Everything else is unverified with the lowest confidence and an empty list: no sources, a single independent source, several mirrors of one origin, or agreement that is entirely stale.

One query, a token budget, and a set of target documents that must match exactly — every target, nothing else. Do not try to reason this out by eye; the index contains decoys that differ from a target in exactly one field.

1. Paste the index into a script. Every document is given to you as structured data. Getting it into a list of records is the whole setup.

2. Implement each operator exactly as the question defines it, not as the real search engine behaves. In particular: the site operator matches the host itself or any subdomain, which means an equality test or a dotted-suffix test — and the date operators are strict on both ends.

3. Diff the targets against the rest. Group all documents by each field in turn and look at which values the targets share and the non-targets don't. This tells you which dimensions are even worth spending tokens on.

4. Find the decoys deliberately. For each candidate token, list the non-targets it fails to exclude. Those near-misses are what your remaining tokens have to kill, and they point straight at which field still needs constraining.

5. Then brute force. Build a pool of candidate tokens — every plausible operator value, plus the negation of each, plus the date thresholds across the full year range — and search combinations up to the token limit. Prefer the shortest query that works.

6. Assert exact set equality before you submit: the matched set equals the target set, with zero extras and zero missing. Print both differences so a near-miss is obvious rather than silent.

Rules top to bottom, first terminal match decides. Three sub-answers, all of which must be right. This is a simulator problem, not a reading problem.

1. Encode the rules as an ordered list of action-and-predicate pairs, in the given order, transcribed one at a time. Most wrong answers here are transcription errors, not logic errors.

2. Model terminality correctly. Block, challenge and skip stop evaluation; the logging action does not and evaluation continues past it. Falling off the end means the request is allowed.

3. Define "reaches the origin" once: the skip outcome or the fell-through-allowed outcome. A challenge does not reach the origin even though it isn't a block.

4. Map every request field to the rule field it is tested against, including the header lookup, and keep the comparison operators honest — the inequality operators are strict, membership tests are exact, and the substring and prefix operators are not the same thing.

5. Answer part one by running all requests and counting.

6. Answer part two by diffing, not by inspection. Build the reordered rule list, run every request through both, and print the list of requests whose outcome changed. The question promises exactly one — if you get zero or several, you have a transcription bug, so go back to step one.

7. Answer part three by rewriting only the one named rule in the original order and re-running the count.

8. Print which rule decided each request. It costs one line and it is how you sanity-check the whole simulator.

Three artefacts, three extractions, no model needed anywhere. All three parts must be right, so verify each one independently rather than trusting a single run.

1. Image — read the bit plane the question names. One specific colour channel, the lowest bit, one bit per pixel, in reading order across then down. Group into bytes most-significant bit first and stop at the first null byte. If you get mojibake, the usual culprits are the wrong channel or column-major traversal.

2. Audio — segment on the silence, then measure. Find the gaps rather than assuming exact sample offsets, but cross-check the segments you find against the nominal tone and gap durations. If the segment count is off, your silence threshold is wrong.

3. Take the dominant frequency per segment with an FFT or Goertzel, then snap to the nearest table entry. Print the measured peak for every tone — each one should land within a few hertz of a table value. If one is halfway between two entries, your window is crossing a boundary.

4. Frames — split the sheet on the stated grid and remember the layout is playback order, reading across rows.

5. Take a robust base colour per tile. The noise is bounded and symmetric, so a per-channel median is the safe estimator. Compare consecutive tiles with a tolerance comfortably above the noise bound and well below a real scene change.

6. Count transitions, not scenes. The answer is the number of adjacent pairs that differ — for a sheet of n frames there are n − 1 pairs to test.

7. Print your evidence: the recovered string, every measured frequency, every base colour and every pairwise delta. If the deltas cluster cleanly into "tiny" and "large" with nothing in between, your count is trustworthy.

Report exactly which findings are present — no more, no fewer. The file is written so that some alarming patterns are genuinely safe and some innocuous ones are not, and listing a finding that isn't there is scored as wrong.

1. Work finding by finding, not line by line. Take each finding code, apply its stated rule to the whole file, and record present or absent with the line that proves it.

2. For the privileged-context finding, look for the combination: a trigger that runs with the base repository's permissions together with a checkout of the pull request's own head. Either one alone is not the finding; the pair is.

3. For pinning, split the actions by namespace first. First-party actions may be referenced by tag and are not findings. For each third-party action, count the reference: it must be exactly forty hexadecimal characters. Check every one — the file mixes pinned and unpinned third-party actions on purpose.

4. For over-broad permissions, compute the union of what the jobs need and compare it against the workflow-level block. If the workflow level grants nothing beyond that union, the finding is absent no matter how the block looks at a glance.

5. For the secret-in-log finding, ask only one question: can the value reach step output. A secret interpolated into an echoed string can. A secret handed to a script through the environment block, where nothing prints it, cannot.

6. For the approval finding, look for an environment attached to the deploying job. Its presence is what carries the protection; a branch condition is not a substitute and its absence is not this finding.

7. For injection, distinguish the two shapes. Event-controlled data interpolated straight into a shell command is the finding. The same value passed through the environment block and referenced as a shell variable is the documented safe form.

8. Then name the abusable job. It is the one where an outside contributor's own code executes while the workflow holds elevated privileges — trace which job checks out and runs code that the contributor controls.