"makanya", "makin", "malah", "malahan", "mampu", "mampukah", "mana", "manakala", "manalagi", "masih", "masihkah", "semasih", "masing", "mau", "maupun", "semaunya", "memang", "mereka", "merekalah", "meski", "meskipun", "semula", "mungkin", "mungkinkah", "nah", "namun", "nanti", "nantinya", "nyaris", "oleh", "olehnya", "seorang", "seseorang", "pada", "padanya", "padahal", "paling", "sepanjang", "pantas", "sepantasnya", "sepantasnyalah", "para", "pasti", "pastilah", "per", "pernah", "pula", "pun", "merupakan",...

"makanya", "makin", "malah", "malahan", "mampu", "mampukah", "mana", "manakala", "manalagi", "masih", "masihkah", "semasih", "masing", "mau", "maupun", "semaunya", "memang", "mereka", "merekalah", "meski", "meskipun", "semula", "mungkin", "mungkinkah", "nah", "namun", "nanti", "nantinya", "nyaris", "oleh", "olehnya", "seorang", "seseorang", "pada", "padanya", "padahal", "paling", "sepanjang", "pantas", "sepantasnya", "sepantasnyalah", "para", "pasti", "pastilah", "per", "pernah", "pula", "pun", "merupakan",...

Since the naming of the properties no longer suggests they are experimental, we want to ensure users are aware if the current property stops having an effect.
Since the underlying feature is incubating, its actual behavior can still change or be removed in the minor releases.

These properties CAN be supplemented with command-line options and they SHOULD follow the shared naming scheme described above.

     */
    @Override
    public Tuple3<String, String, String> createTask(final String path, final Map<String, Object> docMap) {
        final FessConfig fessConfig = ComponentUtil.getFessConfig();
        final String thumbnailId = DocumentUtil.getValue(docMap, fessConfig.getIndexFieldId(), String.class);
        final Tuple3<String, String, String> task = new Tuple3<>(getName(), thumbnailId, path);

This can save everyone a lot of time and frustration.

For any non-trivial change, we need to be able to answer these questions:

* Why is this change done? What's the use case?
* For user-facing features, what will the API look like?
* What test cases should it have? What could go wrong?
* How will it roughly be implemented? We'll happily provide code pointers to save you time.

- Authentication: Local (UserService), LDAP, OIDC, SAML, SPNEGO, Entra ID
- Security features: AES encryption, SHA256 digest, LDAP injection prevention, password policy, rate limiting

## Naming Conventions

| Element | Convention | Example |
|---------|------------|---------|
| Classes | PascalCase | `UserService`, `FessBaseAction` |
| Methods | camelCase + verb | `getUserList()`, `setupHtmlData()` |

## Decision

The Gradle project adopts **American English** as the standard language variant for all code, comments, documentation, user-facing messages, and written communication.

### Examples

Use American English spelling, for example:

* `color` (not `colour`)
* `initialize` (not `initialise`)
* `behavior` (not `behaviour`)

    protected List<OpenSearchUrlQueue> fetchUrlQueueList(final String sessionId) {
        final CrawlingConfigHelper crawlingConfigHelper = ComponentUtil.getCrawlingConfigHelper();
        final CrawlingConfig crawlingConfig = crawlingConfigHelper.get(sessionId);
        final Map<String, String> configParams = crawlingConfig.getConfigParameterMap(ConfigName.CONFIG);

The main logic with ADRs is to describe (architectural) decisions made:

* To provide best practices and solutions we (as the *build tool* team) want to promote.
* To avoid asking the same thing multiple times during code review.
* To explain *rejected solutions*, for now, and future development, in case they are proposed again.

ADRs can be written by any team.

    SUMMARY("summary"),

    /** User is asking a FAQ-type question */
    FAQ("faq"),

    /** Intent is unclear - need to ask user for clarification */
    UNCLEAR("unclear");

    private final String value;

    ChatIntent(final String value) {
        this.value = value;
    }

    /**
     * Returns the string value of this intent.
     *
     * @return the intent value
     */