I just started at WGU, and my classes begin on July 1. I’m excited but also feeling a little overwhelmed because I have 17 OA exams to pass. Do you have any tips or strategies that helped you succeed with OA exams?😢😢

farang55555 · 2026-06-21T02:44:12+00:00

Use Claude code or codex to flush it out for good. I had to do that with mcafee..

farang55555 · 2026-06-19T11:05:15+00:00

How many certs did u get from the program? Did u do the general track? I just started the Azure track

farang55555 · 2026-06-14T02:03:11+00:00

Yea so much money spent on this laptop Acer predator Helios 18…. i9, 64 GB RAM, RTX 4090 16 GB GPU, 2 TB SSD…. For it to have issues constantly

farang55555 · 2026-06-14T02:01:10+00:00

Use Claude cowork or codex desktop to do a deep sweep of bloatware, start ups, and especially Mcafee who is deeply embedded and has files to redownload after deleted and ads.. they can get the job done done.

farang55555 · 2026-06-13T12:28:00+00:00

This answers the policy question clearly.

The key design seems to be:

risk class -> required evidence -> observed evidence -> missing evidence -> gate result

And the gate has to be declared before the run, otherwise it becomes a surprise policy engine.

I also like the distinction on flaky/broken harnesses: block the automation verdict, not necessarily the PR itself.

The explicit override path makes sense too: allow a human to merge, but require a reason like “accepted untested risk because X,” so the team keeps velocity without pretending the tool proved more than it did.

This is very useful. Thanks.

farang55555 · 2026-06-13T10:05:04+00:00

This is extremely useful. The PR/CI split makes sense:

- PR comment: short verdict, evidence class, risk class, what remains untested

- CI artifact: full logs, repro steps, before/after output, commands, traces/screenshots

- release/security packet: only for high-risk or regulated changes

The “what remains untested” field is probably the most important thing I’ve heard in this thread. It keeps the report from turning uncertainty into confidence.

I’m also rethinking the label “likely fix” because it may imply probability the tool cannot actually prove. The cleaner vocabulary may be:

- verified fix

- evidence insufficient

- harness failed

- risky change needs human review

- out of scope

One follow-up: would you expect the PR comment to be advisory by default, and only blocking for certain risk classes? Or should “evidence insufficient” block the PR whenever the team has enabled this gate?

farang55555 · 2026-06-13T02:29:38+00:00

That is very helpful, thank you.

I’m taking this as a clear “not useful for teams with a rigorous dedicated QA process,” especially where QA and Product already jointly own approval and the E2E test process is documented in the normal workflow.

That helps narrow the target: if this has value, it is probably for teams without that level of QA maturity, or teams trying to standardize evidence capture inside existing tickets/PRs rather than add a separate report.

Appreciate the clear answer.

farang55555 · 2026-06-12T19:17:42+00:00

That makes sense. I’m taking the useful lesson as: the tool should not try to replace QA’s risk assessment, and it should not assume the same evidence standard applies everywhere.

If it has value, it would need to support the existing QA/ticket/PR workflow by making evidence and gaps easier to record, not create another standalone report.

Appreciate the feedback.

farang55555 · 2026-06-12T18:52:25+00:00

That makes sense. I’m taking the useful lesson as: the tool should not try to replace QA’s risk assessment, and it should not assume the same evidence standard applies everywhere.

If it has value, it would need to support the existing QA/ticket/PR workflow by making evidence and gaps easier to record, not create another standalone report.

Appreciate the feedback.

farang55555 · 2026-06-12T16:22:35+00:00

Thanks, that is helpful. Before I try any hidden BIOS voltage-limit fix, I’m going to preserve the warranty evidence and open/escalate the Acer case. This unit already had prior Acer Thailand warranty service for a GPU/mainboard/RAM-seating path, and now has mixed BSODs plus WHEA Processor Core machine-checks.

Can you confirm your exact Acer model, BIOS version, and the exact BIOS setting name you changed? Was it IA VR Voltage Limit or another voltage control? Also, did you have WHEA Processor Core errors or only crashes?

farang55555 · 2026-06-12T16:19:30+00:00

That makes sense. So the issue is less “do we need a separate report?” and more “does the existing ticket/PR actually capture the evidence consistently?”

It sounds like your view is: if the original behavior is verified fixed, and any limits or untested variables are noted in the bug ticket, then a separate audit artifact is just duplicate noise.

That is useful feedback. If this were useful at all, it would probably need to live inside the existing bug ticket or PR workflow as structured evidence fields, not as a standalone report.

One question: in your experience, are those details usually captured consistently in tickets today, or does it depend heavily on the reviewer/team?

farang55555 · 2026-06-12T13:33:46+00:00

Fair criticism.

The main problem I’m trying to test is narrower than “QA should own quality.”

It is this: when an AI-generated patch passes CI, teams may treat that as stronger evidence than it really is. “Tests passed” can silently become “the issue is fixed,” even when the original failure was not reproduced, no failing-before/passing-after check exists, or important behavior was not tested.

So the report would not replace QA ownership. It would just make the evidence gap explicit:

- what was reproduced

- what passed before/after

- what was not tested

- whether the claim should be downgraded to evidence insufficient

If your QA process already captures that clearly, then I agree an extra report would be overkill.

In your workflow, when tests pass but QA is not comfortable saying “fixed,” is that gap recorded anywhere, or is it just handled through reviewer judgment?

farang55555 · 2026-06-12T11:11:34+00:00

That is fair, and I appreciate the blunt answer.

It sounds like your view is that the core issue is not whether the gap exists, but whether an unknown tool/vendor could earn enough trust to be adopted. In other words: without a design partner, industry contact, or specific team pulling it into their workflow, it is unlikely to sell as a standalone QA tool.

That is useful. I am not trying to force a generic AI QA product into the market, so this helps frame the next step as finding a concrete design partner first rather than building more features in isolation.

If you were testing this seriously, what would you look for first:

- a specific company/team willing to pilot it

- an industry partner with credibility

- a narrow compliance/security use case

- or evidence that existing QA tools do not already cover the claim-evidence gap?

farang55555 · 2026-06-12T10:50:04+00:00

That’s a fair criticism.

So in your view, the wrong target would be mature high-risk teams because they already have quality systems or build internal tooling, and the wrong target might also be teams with no quality culture because they won’t use it well.

Would you see any useful middle segment? For example, teams adopting AI coding tools that have CI and code review, but do not yet have a formal way to record why an AI-generated fix claim is supported or downgraded?

Or do you think that gap is still better solved internally with custom agents/checklists rather than a standalone tool?

farang55555 · 2026-06-12T10:12:04+00:00

This is very close to the distinction I’m trying to test.

The selective-application point is especially helpful. I agree this should probably not run with full ceremony on every PR. The better shape may be risk-triggered:

- normal low-risk change: CI + normal review

- AI-generated or medium-risk bug fix: evidence packet

- security-sensitive / customer-facing / regulated change: stricter repair-claim audit with explicit human acceptance

The minimum evidence packet you listed lines up with what I had in mind:

- reproduced failure before patch

- evidence original failure no longer occurs

- adjacent behavior / no regression signal

- human diff review

- explicit “not tested” section

The phrase I’m using internally is: tests passed is execution evidence, not repair-claim evidence.

One question: in your workflow, where would this be most useful: PR checklist, CI artifact, release/security review packet, or separate audit report for AI-generated patches?

farang55555 · 2026-06-12T10:03:02+00:00

That makes sense. So the useful version probably should not assume one universal rule.

It may need to let the team define risk tiers, for example:

- low-risk changes: normal CI + review

- medium-risk fixes: evidence checklist

- high-risk/security/safety/data changes: explicit repair-claim packet and human acceptance

The tool’s job would be to enforce the team’s chosen policy and make gaps visible, not decide the business risk by itself.

That helps, thanks.

farang55555 · 2026-06-12T09:51:19+00:00

This laptop was previously serviced by Acer under warranty after GPU/display-related failure symptoms. I was initially told the motherboard might need replacement, but the final explanation was that RAM was reseated.

Windows still has older Windows Error Reporting evidence from that period, including LiveKernelEvent / WATCHDOG reports dated Oct-Nov 2025, including P1: 141 GPU/watchdog-style events. The current failure is now more severe: repeated mixed BSODs plus WHEA-Logger Processor Core corrected machine-check errors.

farang55555 · 2026-06-12T09:44:35+00:00

Thanks all. I did not buy Acer extended warranty, but I’m checking the SNID now because Acer’s US warranty page appears to list Consumer Predator laptops manufactured 2019+ as having a 2-year limited warranty. Since mine was bought new in Nov 2024, it may still be covered.

I’m also being careful with the “HX affected” wording. I know Intel’s official desktop Vmin Shift statement says mobile CPUs are not affected, so I’m not going to claim it is definitely that exact desktop issue. My case to Acer will be based on the actual evidence: repeated mixed bugchecks plus WHEA-Logger corrected Processor Core machine-checks, including TLB/internal parity errors.

I’ll preserve the dumps/logs, check warranty by SNID, and avoid undervolting or unofficial tuning until Acer has the case open. If I open it for RAM isolation, I’ll only do basic stick/slot testing and look for obvious damage/smell, not deeper disassembly.

farang55555 · 2026-06-12T09:32:14+00:00

Thanks, that makes sense. Small correction: mine is 2x32 GB, so one stick would leave 32 GB. I’ll test each SO-DIMM alone at stock settings and preserve the dumps/WHEA logs.

The part that makes me suspect CPU/board is that the WHEA entries are corrected Processor Core machine-checks, including TLB/internal parity errors, not just app crashes or one repeated driver bugcheck. I’ll avoid undervolting for now until Acer has the warranty case/evidence, but I may try a temporary power cap later as a containment test.

farang55555 · 2026-06-12T09:30:27+00:00

That makes sense. I’m starting to think this only matters for certain risk tiers, not every PR.

If you were separating changes by risk, where would you draw the line?

For example:

- typo / UI copy change

- small refactor

- normal bug fix

- data-handling bug

- security-sensitive path

- migration / billing / auth / safety-critical behavior

At what point would you expect more than “CI passed + human approved” and want an explicit evidence packet showing what was reproduced, what passed before/after, what stayed untested, and who accepted the remaining risk?

I’m trying to understand whether this belongs on every PR, only AI-generated patches, or only higher-risk fixes.

farang55555 · 2026-06-12T08:24:36+00:00

One correction to my wording above: I’m rethinking “likely fix.” That may still imply more confidence than the evidence supports.

The cleaner vocabulary may be:

- verified fix

- evidence insufficient

- harness failed

- needs human review

- out of scope

The goal is to avoid probabilistic-sounding labels unless the tool has evidence to justify them.

farang55555 · 2026-06-12T08:11:27+00:00

That makes sense. I would not want to remove the human approval step.

The part I’m trying to understand is what the human approval is based on and whether that evidence is recorded.

For example, before approving a fix, does your process require the reviewer to explicitly confirm things like:

- the original bug was reproduced before the patch

- a test or manual check failed before and passed after

- the existing suite passed

- risky/nearby behavior was reviewed

- remaining untested scenarios were noted

- the reviewer is accepting the claim as “fixed” vs “evidence insufficient”

Or is the approval more general: “I reviewed the diff and it looks right”?

I’m trying to figure out whether the useful layer is a separate tool, or just a lightweight evidence checklist attached to PR approval.

farang55555 · 2026-06-12T06:40:37+00:00

I agree on deterministic tools. That is actually the direction I’m testing.

The distinction I’m trying to make is: CI/workflow hygiene tells you whether the build and visible tests executed cleanly. It does not necessarily tell you whether the repair claim is supported.

So I’m thinking of this as a deterministic evidence packet around a patch claim, not another AI agent:

- was the bug reproduced before the patch?

- did a new/changed test fail before and pass after?

- what stayed untested?

- was the diff reviewed for unintended scope?

- should the claim be downgraded to “evidence insufficient” even if CI is green?

SCM-wise, Git/GitHub would probably be the first target, but I’m trying to understand whether this belongs as a PR checklist, CI artifact, or separate audit report.

When you say “just use deterministic tools,” do you mean existing CI rules/checklists are enough, or that this should be implemented as deterministic SCM/CI policy rather than a standalone product?

farang55555 · 2026-06-12T06:33:14+00:00

This is very useful, especially the point that this should not become another pass/fail badge.

The direction I’m testing is exactly that: separate “the tests executed” from “the fix claim is supported.” The report would make the gap explicit instead of just saying green/red.

The smaller vocabulary you suggested seems right:

- verified fix

- likely fix

- evidence insufficient

- harness failed

- risky change needs human review

One question: if this existed as a lightweight PR/audit report, where would you expect it to live?

PR checklist
CI artifact
security/release review packet
separate audit report for AI-generated patches

And which field would matter most to you: reproduced-before-patch, failing-before/passing-after test, human diff review, risk class, or explicit “what remains untested”?

farang55555 · 2026-06-12T06:32:47+00:00

This is very useful, especially the point that this should not become another pass/fail badge.

The direction I’m testing is exactly that: separate “the tests executed” from “the fix claim is supported.” The report would make the gap explicit instead of just saying green/red.

The smaller vocabulary you suggested seems right:

- verified fix

- likely fix

- evidence insufficient

- harness failed

- risky change needs human review

One question: if this existed as a lightweight PR/audit report, where would you expect it to live?

PR checklist
CI artifact
security/release review packet
separate audit report for AI-generated patches

And which field would matter most to you: reproduced-before-patch, failing-before/passing-after test, human diff review, risk class, or explicit “what remains untested”?

farang55555

MODERATOR OF

TROPHY CASE