Operational Questions Belong in Project Views

GitHub made advanced search for Projects generally available on 16 July. Project views can now use logical AND and OR expressions instead of creating a separate saved view for every question. The same update added a reviews: filter for pull request items and introduced a 90-day retention policy for deployment statuses in the API.

Vercel shipped two nearby signals. ISR Observability now shows write utilization, a ratio of cached requests to ISR writes that helps find routes regenerating often but serving few cached hits. On 17 July, Chat SDK added native Slack agent support, including suggested prompts, agent-view context, streamed replies, rotating status messages, and feedback buttons.

Read together, these are not just product updates. They show a shift from dashboards that display work to interfaces that answer operational questions.

The repeated angle to avoid

Recent posts here have covered runtime credentials, dependency cooldowns, Copilot security reviews, alert-name playbooks, repository operating maps, prompt-injection triage, pull request dashboards, AI coding telemetry, accessibility-tree testing, feature-flag diffs, cache variants, and pointer-event contracts. Older related posts also covered model routing, cost budgets, permission budgets, deploy dry runs, and analytics checks.

The weak version of this article would repeat the old X needs Y pattern: project boards need better filters. The sharper thesis is that product and engineering queues are becoming queryable control planes. Builders should design the questions first, then decide which fields, metrics, retention windows, and agent prompts are allowed to drive action.

A filter is a policy in disguise

Advanced project search sounds like a convenience feature until a team starts depending on it. A view such as status:ready AND reviews:required is not only a list. It is a definition of what the team believes is waiting for human attention. A view such as risk:high AND (status:blocked OR status:in-review) becomes a release-risk queue.

That matters because small teams often manage important work with the same flat board:

• quote-form bugs beside copy edits;
• checkout and analytics changes beside dependency updates;
• AI-agent tasks beside human-authored pull requests;
• deployment questions beside feature requests;
• support fixes beside marketing experiments.

A board can look organised while still hiding the question that matters today. The practical improvement is to name the question in the view.

Operator question	Useful view expression	Required field discipline
What can block today's release?	release:current AND (status:blocked OR status:in-review)	Every item has a release marker and owner.
Which high-risk PRs are waiting on people?	risk:high AND reviews:required	Pull request items carry risk and review state.
Which agent tasks may change production?	actor:agent AND (environment:production OR risk:high)	Agent-created work is labelled by actor and environment.
Which stale deploy notes should not be trusted?	deployment:evidence AND updated:<90d	Deployment evidence has an age rule.
Which customer-path defects escaped routine review?	surface:checkout OR surface:booking OR surface:lead-routing	Business surfaces are first-class labels.

The exact syntax will vary by tool and field setup. The habit is the same: views should answer a named operating question, not just group tickets by status.

Deployment evidence now has a shelf life

GitHub's 90-day retention policy for deployment statuses is easy to overlook. A deployment's current state remains unaffected, but older statuses are deleted from the REST and GraphQL APIs. That is a reasonable platform policy, yet it has a consequence for teams that use deployment statuses as historical evidence.

If a release review, incident report, compliance note, or customer escalation depends on old deployment status data, the project board should not pretend that evidence lasts forever.

Use a simple evidence rule:

deployment_evidence_policy:
  current_state_source: hosting platform or deployment API
  short_term_window: deployment statuses and checks available in normal tooling
  long_term_record:
    keep:
      - commit sha
      - deployment id or URL
      - environment
      - release owner
      - validation summary
      - rollback reference
      - incident or change ticket link
  refresh_if:
    - release is referenced in a postmortem
    - customer-impacting change remains under review
    - regulated or contractual evidence is needed beyond API retention

This is not bureaucracy. It prevents an operator from opening an old project item six months later and assuming the missing API status means the deployment never happened, or that a current status proves the release was safe at the time.

Cache writes turn performance into a queue question

Vercel's write utilization metric is useful because it converts a vague caching worry into a route-level question: which pages regenerate often but do not serve enough cached requests to justify the write cost?

That belongs in the same operating model as project search. A route with low write utilization may need a longer revalidation interval, on-demand revalidation, different content freshness rules, or a product decision that the route is not worth regenerating so often.

For a small business site, the triage should not be optimize all ISR pages. It should be:

Route pattern	Low write utilization means	Likely action
Blog or guide pages	Content is regenerating more often than readers benefit from	Increase revalidation interval or trigger on publish.
Product category pages	Inventory, price, or merchandising rules may be too chatty	Separate critical fields from decorative freshness.
Local-service area pages	Many long-tail pages may have little traffic	Batch updates and regenerate on content change.
Checkout-adjacent pages	Cost may be acceptable if freshness protects revenue	Keep faster revalidation but watch business metrics.
Internal dashboards	Cache strategy may not match actual usage	Consider dynamic rendering or authenticated data paths.

The operator asset is a saved queue, not a one-off investigation: low_write_utilization AND surface:not-checkout for routine cost reduction, and low_write_utilization AND surface:checkout for careful review rather than automatic slowing.

Slack agents need promptable boundaries

Native Slack agent support in Chat SDK is a different kind of interface, but it points at the same discipline. Suggested prompts, agent-view context, streaming replies, status messages, and feedback buttons can make an internal agent feel like part of the team's normal communication flow.

That is useful only if the prompts match the agent's authority. A Slack agent that can summarise a project is different from one that can open issues, query metrics, change flags, or draft customer messages. The user experience should make that boundary visible.

A practical Slack agent prompt set might look like this:

slack_agent_operating_prompts:
  safe_default:
    - title: Show today's blocked release items
      action: read project view only
    - title: Explain low ISR write utilization routes
      action: read metrics and suggest changes
    - title: Summarise PRs waiting for review
      action: read pull request state
  requires_human_approval:
    - title: Open follow-up issues for high-risk routes
      action: create issue drafts, require confirmation
    - title: Change revalidation settings
      action: propose pull request, require reviewer
    - title: Message customers or sales leads
      action: draft only, never send automatically
  must_not_offer:
    - merge release pull requests
    - change production flags
    - rotate credentials
    - delete deployment or incident records

The prompt list becomes a contract. If the agent is presented inside Slack, people will treat it as a teammate. The interface should make safe questions easy and dangerous actions explicit.

Failure modes when queues become action surfaces

More queryable interfaces can make operations better, but they also create new ways to be confidently wrong.

• Field theatre: views use elegant search expressions, but items are missing risk, surface, owner, or environment fields.
• Metric automation without context: low write utilization triggers caching changes on revenue-critical routes without checking freshness needs.
• Retention amnesia: old deployment status data disappears from APIs, but the team never captured a durable release record.
• Agent prompt drift: Slack suggested prompts encourage broader actions than the bot is actually allowed to perform safely.
• One dashboard per symptom: project search, cache metrics, and agent conversations remain separate, so no one can see that the same release caused all three signals.

The fix is not to centralise everything into one mega-dashboard. It is to make each surface answer a specific operating question and preserve the evidence needed to trust the answer.

A practical design rule

Before adding another project view, observability column, or agent prompt, write the question in plain English:

1. Who will use this answer? Developer, founder, release owner, support lead, or agent.
2. What decision can it change? Review now, delay release, adjust cache policy, create issue, escalate incident, or do nothing.
3. Which fields or metrics must be reliable? Risk, surface, review state, route, write utilization, environment, actor, owner, or age.
4. What evidence expires? Deployment statuses, logs, metrics windows, temporary previews, or Slack thread context.
5. What action is forbidden from this surface? Merge, deploy, message customers, rotate secrets, change flags, or alter pricing.

If the team cannot answer those five questions, the new view is probably just another inbox. If it can, the view becomes an operating instrument: narrow enough to trust, searchable enough to act on, and explicit about where humans still need to decide.