DEV Community: Enoch Chan

CRA reporting starts 11 September: make the first 24 hours less improvised

Enoch Chan — Wed, 09 Sep 2026 11:16:57 +0000

The first-hours check

From 11 September 2026, CRA reporting obligations start applying to manufacturers for actively exploited vulnerabilities and severe incidents affecting product security. The early warning can be due within 24 hours of becoming aware.

That makes the first operational question very concrete: who records awareness, who performs the human reportability assessment, who decides the reporting path, and where is the supporting evidence collected?

The useful preparation is not to automate the legal decision. It is to make the handoff and evidence trail explicit before a real incident.

A free synthetic tabletop is available here: https://cra-incident-desk.solarclabs.com/

The useful preparation is explicit ownership: record when the team became aware, route the case to human triage, preserve the first evidence, and rehearse the handoff before an incident starts the clock. This is preparation support, not an automated legal decision or regulatory submission.

UK EPR packaging data: make evidence gaps explicit before filing

Enoch Chan — Tue, 08 Sep 2026 07:14:01 +0000

Make EPR evidence gaps explicit

Large producers' January-June 2026 packaging data is due by 1 October 2026. For specified primary or shipment packaging, sufficient evidence is required to support non-household treatment. If that evidence is unavailable, keep the uncertainty visible and route the row for review before treating a tidy CSV as ready.

This is an operating check, not a legal-classification decision or an acceptance guarantee. The useful sequence is simple: identify the rows nobody can defend, preserve the supporting source, and queue the missing evidence before filing.

How to answer a security questionnaire without guessing

Enoch Chan — Sun, 06 Sep 2026 22:56:16 +0000

How to answer a security questionnaire without guessing

A customer security questionnaire is easy to treat as a spreadsheet exercise. That is where the risk starts. A row is not just a box to fill: it is a claim that someone may rely on when deciding whether to buy, renew or approve a supplier.

Use a four-part record for every meaningful question:

Scope — What service, environment, data set or process does the question actually cover?
Claim — What precise statement are you making? Avoid turning a narrow fact into a broad promise.
Evidence — Which current policy, configuration record, test result, report or operating record supports the claim?
Owner — Who is authorised to approve the wording and confirm that the evidence still applies?

This is consistent with the evidence-led shape of supplier due diligence. NIST describes due diligence as researching pertinent supplier information so an organisation can make an informed decision. UK guidance also points toward proportionate, staged evidence rather than asking every supplier for every possible document at the start.

A reusable answer library can reduce re-entry, but reuse is not the same as copy-and-paste. Preserve the source, scope, review date and owner with the answer. When a buyer changes the question or the service changes, send the row back through review.

A useful final check is simple: could another reviewer open the answer, understand exactly what it claims, find the supporting evidence and see who approved it? If not, the row is not ready to leave the team.

This workflow does not guarantee procurement approval. It makes the answer easier to review, easier to update and harder to overstate.

E-invoice states: accepted is not the same as validated

Enoch Chan — Sun, 06 Sep 2026 20:14:15 +0000

Accepted is not validated

An e-invoice workflow can show an accepted import before the work that matters operationally is complete. The useful model is not one green success flag. It is a sequence of states that can be inspected separately: parsed, validated, routed and accepted.

The Pennylane import documentation says a successful response confirms that a file was accepted and parsed. It also documents that sending can happen before Schematron validation completes, and that an invalid invoice may be rejected later by the platform. That does not mean every accepted invoice will fail. It means the first response should not erase the later checkpoints.

Pennylane also distinguishes a technical or non-conformity rejection from a customer refusal. Those outcomes belong to different parts of the workflow and need different owners. If a team collapses them into one status, an incident review becomes guesswork.

For an integration rollout, keep these questions visible: what was parsed, what was validated, where was it routed, and what final outcome did the platform or recipient return? When failures repeat across a batch, inspect the source system and its mapping rather than treating each invoice as an isolated mystery.

This is an operational workflow model, not legal or tax advice. Review the InvoiceBatch FR scope when you need a bounded way to inspect the product context.

AI social automation: automate the loop, not the publish button

Enoch Chan — Sat, 05 Sep 2026 22:28:56 +0000

A reviewable workflow for social publishing

A useful publishing workflow separates a change signal from a public post. Start by monitoring a useful change, verify the source, turn the checked idea into a draft, review the exact draft, and schedule only after the checkpoint is complete. This keeps the workflow understandable and makes the publication boundary explicit.

Monitor and verify

Monitoring identifies a change worth examining. Verification checks the source and the specific detail that supports the draft. Do not treat a signal as approval, and do not turn an unverified idea into a public message.

Draft and review

Use the draft as a reversible working state. Review the exact wording, media and destination before the calendar step. A reviewer should be able to see what will be scheduled and why it is ready.

Schedule last

The final sequence is simple:

Monitor the useful change.
Verify the source.
Draft the message.
Review the exact content.
Schedule after approval.

Selected source references:

Scheduled tasks in scheduled tasks: https://help.openai.com/en/articles/10291617-scheduled-tasks-in-chatgpt
Automating repetitive work with Codex: https://developers.openai.com/blog/automating-repetitive-work-at-openai-with-codex
Create Post: https://docs.postiz.com/public-api/posts/create
Postiz MCP: https://postiz.com/mcp

Google Preferred Sources: reader choice, not a ranking guarantee

Enoch Chan — Mon, 24 Aug 2026 09:41:16 +0000

Google Preferred Sources: reader choice, not a ranking guarantee

Google documents an interactive Preferred Sources button that can return readers to the page after they complete the selection flow. For publishers, the useful question is not how to promise a search outcome. It is where a reader who already values the publication can make a preference explicit and continue reading.

The safe message is simple: make the action easy to find, explain what the reader is confirming, and keep the experience tied to an existing trust moment such as the article end or publication information area. Do not turn that reader preference into a ranking, traffic, or eligibility guarantee.

A short implementation review can therefore follow three steps: choose, confirm, and return. The page should make the action understandable without imitating Google UI or inventing proof. The exact Google documentation remains the source for the feature details and eligibility boundaries.

Hydrogen pageviews: verify what client-side navigation actually emits

Enoch Chan — Sat, 22 Aug 2026 22:18:53 +0000

Hydrogen pageviews: verify what client-side navigation actually emits

Shopify's August 18, 2026 Hydrogen developer preview includes a specific observability change: every navigation now emits a page view. The safe takeaway is scoped. It is not a claim that every Shopify storefront was losing pageviews, and it is not a promise of better revenue attribution. It is a reason to test the Hydrogen version and analytics path you actually run.

The useful test

Start with one initial page load. Navigate through two client-side routes. Then inspect the events that arrived, including their route context and timestamps. Compare what your instrumentation recorded with the navigation sequence you performed.

Why the distinction matters

A single recorded pageview can hide what happened after the first load when a storefront behaves like an app. Treating the first load as the whole session can make a team reason from incomplete telemetry. The practical check is simple: load, navigate, verify.

Keep the result tied to the Hydrogen developer preview scope described by Shopify. If the event trail differs from the behaviour described in the preview, record the deployed version and investigate the analytics integration rather than generalising from one test.

Source: Shopify Hydrogen developer preview update: August 18, 2026.

From views to a feedback loop: a three-step rule for new accounts

Enoch Chan — Fri, 21 Aug 2026 07:17:31 +0000

Views are exposure, not a conversation

YouTube's official creator guidance makes a useful distinction: views do not automatically equal fans, and community is built through conversation rather than monologue. The exact Shorts features are platform-specific, so the transferable idea is a behaviour loop rather than a universal feature claim.

The loop

Ask one answerable question. Listen for repeated answers, objections or examples. Reply with the next useful post. That changes a one-way calendar into a feedback loop: POST → RESPONSE → NEXT POST.

The point is not manufactured comments or a guaranteed audience outcome. It is to make participation easy enough that a real response can shape what comes next. The source describes polls, quizzes, Q&A, Add Yours stickers and video replies as YouTube Shorts features; use those examples only on YouTube and adapt the underlying conversation mechanic carefully elsewhere.

A practical check

Before publishing, ask: what can someone answer in one sentence, what response would change the next post, and how will the reply visibly acknowledge that input? Those questions turn a broad audience-growth ambition into an observable editorial workflow.

Source: https://blog.youtube/creator-and-artist-stories/grow-youtube-channel-interactive-shorts/

Why integrations fail quietly

Enoch Chan — Wed, 19 Aug 2026 08:34:53 +0000

Why integrations fail quietly

An integration can be technically connected while still being operationally fragile. A request may time out, a downstream system may reject a value, or a retry may happen without anyone knowing what changed. The danger is not only the error. It is the silence around the error.

A useful first step is to map one real workflow from request to outcome. Name the system that owns each important field. Decide which failures are safe to retry and which need a human decision. Then log the handoff in a way that lets someone answer three questions: what happened, where did it stop, and what should happen next?

This is a small control loop, not a promise to connect every tool. Start with one flow, make the failure path visible, and only then add more automation.

Search Beyond Your Website

Enoch Chan — Mon, 17 Aug 2026 10:04:33 +0000

Search beyond your website

Social and video teams often judge a post through native reach, likes, comments or watch time. Google discovery is a separate evidence layer, and it can answer a different question: which posts and queries are earning attention from Google Search and Discover?

Google Search Console platform properties can show how Instagram, TikTok, X and YouTube content performs on Google Search and Discover. The reporting can also show which queries and posts drive Google discovery, including clicks and impressions.

That does not make Search Console a replacement for native analytics. Google discovery is not total in-platform reach or engagement, and discovery alone does not prove conversion. The useful workflow is to keep the two layers separate, then compare them before choosing the next topic or format.

A bounded review rule

Start with the native-platform signal your team already tracks.
Check the relevant Search Console platform property.
Compare the queries and posts earning Google discovery.
Choose the next experiment only after looking at both evidence layers.

This keeps a discovery signal from becoming an exaggerated reach claim. It also gives content operators a practical reason to review search data alongside their existing social workflow.

The source for the platform-property claim is Google Search Central.

Inventory Moved Buckets, Not Totals

Enoch Chan — Sun, 16 Aug 2026 19:19:08 +0000

Inventory moved buckets, not totals

Shopify says certain active holds from draft orders and transfer shipments are moving from reserved to committed. The available, on-hand and total inventory values remain unchanged in this migration.

That distinction matters in competitor research and operations reporting. A bucket label can move while the underlying inventory totals stay fixed. If a dashboard only shows the bucket delta, it is easy to escalate a reporting migration as though stock changed.

A bounded review rule

Timestamp the change — record when the bucket movement appeared.
Add platform context — note the Shopify change before interpreting the metric.
Check the totals — compare available, on-hand and total before calling it a real stock event.

This is a measurement and systems-design rule, not a claim that every reserved inventory movement is covered. The Shopify changelog is the source for the specific migration.

Can an EPOS Audit Trail Prove What Changed?

Enoch Chan — Sat, 15 Aug 2026 22:05:28 +0000

Can an EPOS audit trail prove what changed?

HMRC is consulting on proposed EPOS/MPOS software standards until 18 August 2026. The proposed package includes an unalterable and complete transaction log with individual transactions and adjustments indelibly linked in an encrypted chain. These are consultation-stage proposals, not current final standards.

The practical engineering question is broader than the policy context: when a sale changes, does the system preserve the original state, record the adjustment explicitly and keep the relationship between both states traceable? A final value by itself may be easy to read, but it does not necessarily explain what changed or how a reviewer can reconstruct the path.

A simple review rule

Use three visible states:

Original — retain the first recorded transaction.
Adjustment — represent the correction as a distinct event.
Linked history — preserve the relationship so the change can be followed later.

This is an audit-trail design test, not tax advice and not a claim that the consultation proposals are already mandatory. The HM Revenue & Customs consultation is the source for the policy context; the implementation process and timeline have not yet been decided.