Not translated yet — showing English.

Extensibility

Every platform scenario is a chain of registered functions: replace a link or wrap it. You change the platform's behaviour by replacing its steps, not by forking its source.

When to use it

• A platform step must run your logic: declare the replacement for a named link with [Override(…)].
• You need checks or side effects around a step: ordered Before/After middleware that can veto or notify.
• Code must run on a schedule, an event or a webhook: triggers hand you a parsed, typed context.
• You must know what will actually run before deploy: dry-run a chain and read the resolved order.
• Skip it when the rule concerns one entity's writes. A Data hook is the lighter form.

Who does what

At a glance

// gate one named step of the auth scenario — a before hook may refuse, fail-closed
[Before(Auth.SignIn)]
public static Task<Verdict> GateRegion(SignInAttempt a) =>
    a.Region == "sanctioned"
        ? Hook.Reject(Problem.Forbidden, "region not served")
        : Hook.Continue(a);

// wrap a step with ordered middleware
PlayServ.Extend.Scenario("commerce.purchase")
    .Before("grant", LogPurchaseIntent)
    .After("grant", NotifySquad, order: 10);

// customer code on a trigger
[OnSchedule("0 4 * * *")]
public static async Task NightlyCleanup() { ... }

// gate one named step of the auth scenario — a before hook may refuse, fail-closed
export const gateRegion = before(Auth.signIn, (a: SignInAttempt) =>
  a.region === 'sanctioned'
    ? Hook.reject(Problem.forbidden, 'region not served')
    : Hook.continue(a));

// wrap a step with ordered middleware
playserv.extend.scenario('commerce.purchase')
  .before('grant', logPurchaseIntent)
  .after('grant', notifySquad, { order: 10 });

// customer code on a trigger
export const nightlyCleanup = onSchedule('0 4 * * *', async () => { /* ... */ });

# gate one named step of the auth scenario — a before hook may refuse, fail-closed
@before(auth.sign_in)
async def gate_region(a):
    if a.region == "sanctioned":
        return hook.reject(problem.FORBIDDEN, "region not served")
    return hook.cont(a)

# wrap a step with ordered middleware
playserv.extend.scenario("commerce.purchase") \
    .before("grant", log_purchase_intent) \
    .after("grant", notify_squad, order=10)

# customer code on a trigger
@on_schedule("0 4 * * *")
async def nightly_cleanup(): ...

The model

What the platform gives you to attach to.

What a hook declares.

Three ways to attach code.

Where a call goes, and what is true of every route.

What a constraint between hooks is, and when it is checked.

[Rpc("resolve_price", Default = true)]
public static Price ResolvePrice(Sku sku) => Pricing.Base(sku);

[Rpc("resolve_price", When = "env == 'staging'")]
public static Price ResolvePriceStaging(Sku sku) => Pricing.WithDiscount(sku, 0.5f);

// a hook can carry a version too, gated by its own condition
[After("grant", When = "audience == 'beta'")]
public static void NotifySquadBeta(GrantResult r) => Messaging.PingBeta(r.Squad);

export const resolvePrice = rpc('resolve_price', { default: true },
  (sku: Sku) => Pricing.base(sku));

export const resolvePriceStaging = rpc('resolve_price', { when: "env == 'staging'" },
  (sku: Sku) => Pricing.withDiscount(sku, 0.5));

// a hook can carry a version too, gated by its own condition
export const notifySquadBeta = after('grant', { when: "audience == 'beta'" },
  (r: GrantResult) => Messaging.pingBeta(r.squad));

@rpc("resolve_price", default=True)
def resolve_price(sku: Sku) -> Price:
    return pricing.base(sku)

@rpc("resolve_price", when="env == 'staging'")
def resolve_price_staging(sku: Sku) -> Price:
    return pricing.with_discount(sku, 0.5)

# a hook can carry a version too, gated by its own condition
@after("grant", when="audience == 'beta'")
def notify_squad_beta(r: GrantResult):
    messaging.ping_beta(r.squad)

The platform's own logic can be pulled, edited and redeployed. It is functions, like yours:

playserv functions pull matchmaking.match     # the platform's implementation, as source
# edit: widen the skill window for the weekend event
playserv push                                 # your version registers; the default stays as fallback

What you customise here is logic: the overrides, middleware and versions this page is about.

Errors

• A name that matches no registered handler answers not found — a call is never quietly dropped because nobody was listening.
• A name registered twice, and a set with two implementations claiming the same condition, are refused when the set is declared : at deploy, not at call time.
• A hook's refusal carries the hook's own code and reason, so "a rule of the game said no" never arrives looking like a transport failure.
• A hook that fails behaves by its declared kind — fail-open or fail-closed — and which one it is was declared rather than inferred from what happened.
• A hook may not change what is already claimed: not the owner, not the target, not the board or conversation a call was addressed to. It corrects inputs and returns a verdict.

Limits

The numbers arrive with the platform limits chapter; what happens at each ceiling is fixed now.

• A hook's execution deadline: past it, the failure behaviour its kind declares.
• Hooks at one position, and implementations of one method: registering another is refused.
• The nesting depth of "a hook invokes an operation that has hooks": a declared refusal, never resource exhaustion.
• The size of the context passed to a hook: truncation is forbidden, so registration is refused instead of a handler receiving half a context.

Lessons & recipes: a leaderboard in Tanks uses this module's hooks; a daily tournament runs through this module.