Write an integration check without secrets

1297. Lesson identity

Module

3.12 — Steam integration

Lesson

Write an integration check without secrets

Academic type

Workflow

Schema type

mixed

Order

2 of the module

Estimated time

45–60 minutes, including practice

This lesson defines a safe verification workflow for platform integration. The output is a Steam integration matrix organized around five canonical fields: who owns the behavior, what configuration it requires, how it will be tested, how failure behaves, and what evidence is sufficient.

1298. Learning objective

After this lesson, you can produce a Steam integration matrix with explicit ownership, configuration placeholders, test modes, failure behavior, and evidence requirements without exposing credentials.

1299. Why this matters

Platform work becomes risky when a vague statement such as “Steam works” is treated as a test result. A useful integration check identifies the responsible boundary, distinguishes configuration from runtime behavior, and records what can actually be demonstrated in the current environment. This lets you direct AI precisely without giving it secrets or allowing it to imply that an unperformed test passed. The result is a bounded engineering decision rather than a promise based on configuration alone.

1300. Prior knowledge

You should already be able to distinguish store configuration, the Steam client, and the running game as separate boundaries. You should also be able to describe runtime integration behavior and its fallback when the platform client is unavailable. This lesson builds directly on Store, client, and game are different boundaries.

1301. Core concept

An integration check is a bounded claim supported by observable evidence. The matrix must separate five questions:

1. Ownership: Which boundary owns the behavior or configuration—the store, the platform client, the game runtime, or the test harness?
2. Configuration: Which public value, local fixture, or placeholder is required? Never place a real secret in the lesson artifact.
3. Test mode: In what controlled mode will the check run, such as a local fixture, unavailable-client simulation, or designated test build?
4. Failure behavior: What happens when the dependency is absent, invalid, or unavailable?
5. Evidence: What artifact, log, screenshot, or test output supports only the stated claim?

Use placeholders such as <STEAM_APP_ID>, <TEST_BUILD_ID>, or <PLATFORM_CLIENT_STATE>. A placeholder documents an interface requirement; it does not prove that the value is valid or that the integration has been exercised.

1302. Mental model

Use the Ownership → Configuration → Test mode → Failure behavior → Evidence matrix:

A matrix row should describe one behavior and identify its owner. Configuration is not evidence, and a test mode is not a production claim. The matrix is complete only when every row has all five fields and its evidence boundary is clear.

1303. Concrete example

Suppose the check concerns client availability. A bounded row could be written as follows:

Claim boundary: This row verifies the game’s handling of two controlled availability states. It does not verify account ownership, store metadata, a live service response, or production readiness.

This structure prevents two common category errors. A configured application identifier can belong in the configuration field, but its presence does not prove runtime behavior. Likewise, a local fixture can demonstrate the game’s response to an unavailable client, but it cannot prove that a live platform client will return the same state.

1304. AI-native workflow

Use AI as a drafting and challenge partner, not as a source of unverified platform evidence.

1. Give AI the ownership boundaries and the single behavior you want to check. Use placeholders instead of application keys, account data, tokens, or private configuration.
2. Ask it to draft one matrix row with the five canonical fields: ownership, configuration, test mode, failure behavior, and evidence.
3. Ask it to challenge the row: “What would this check fail to prove?”
4. Compare the draft with the observable behavior available in your test environment.
5. Rewrite the row so that its evidence requirement can be satisfied without secrets.
6. Ask AI to inspect the final matrix for secret-shaped values, ambiguous success claims, missing failure behavior, unclear ownership, and rows that combine multiple capabilities.

A suitable instruction is:

Draft one Steam integration matrix row for this single behavior. Include ownership, configuration using placeholders only, test mode, expected and failure behavior, evidence, and the claim boundary. Do not invent API responses, credentials, or completed test results.

The learner remains responsible for deciding whether the evidence is real and whether the scope is honest. AI may improve the wording; it cannot convert an unrun check into a passed check.

1305. Common mistake

The most common mistake is treating configuration presence as runtime verification. Seeing a placeholder, an application identifier, or a configured client path does not prove that the game can use the dependency. Another frequent mistake is writing “fails gracefully” without naming the owner, test mode, visible behavior, continuation rule, and evidence needed to confirm it. A check with no defined test mode or failure case is incomplete even if its success path is clear.

1306. Guided practice

Create a matrix with at least four rows for a hypothetical Steam integration review. Use these single-behavior scopes:

1. The game detects whether the platform client is available.
2. The game handles an unavailable client without blocking the main loop.
3. A configured application identifier crosses the intended boundary without exposing a secret.
4. A diagnostic result is recorded in a way that can be reviewed without account data.

For every row, complete exactly these fields:

• ownership: the boundary responsible for the behavior or configuration;
• configuration: a public value, controlled fixture, or placeholder;
• test mode: the controlled conditions under which the check is exercised;
• failure behavior: the observable response when the dependency is absent, invalid, or unavailable; and
• evidence: the artifact that supports the claim and the claim boundary it does not support.

Then make one deliberate scope decision: choose one row and narrow its claim until the evidence could support it without a live credential. Record what you removed, which field changed, and why. Do not use real credentials, account information, private tokens, or copied secret values in the matrix.

1307. Validation / evidence

Your work is valid when another developer can inspect the matrix and answer all of these questions without asking for a secret:

• Which boundary owns each behavior or configuration item?
• Which values are placeholders or controlled fixtures?
• In what test mode is each row exercised?
• What happens when the dependency is missing, invalid, or unavailable?
• What evidence must be collected?
• What does that evidence explicitly fail to prove?

Submit the matrix as your lesson evidence. A strong submission contains at least four single-behavior rows, fills all five canonical fields for every row, includes available and unavailable paths, uses no secret-shaped values, and avoids claiming that a live platform response was verified when it was not executed.

1308. Key takeaways

• Ownership distinguishes responsibility from configuration and runtime observation.
• Placeholders document required interfaces without exposing credentials or implying valid live configuration.
• A test mode defines how a behavior is exercised; it does not expand the claim to production.
• Every row needs explicit failure behavior and evidence with a stated boundary.
• AI can draft and challenge the matrix, but the learner must verify scope and evidence.

1309. Next lesson

Continue to Version identity has more than one meaning / La identidad de versión tiene más de un significado.

1310. Knowledge check